Engineering leadership when the team ships agents
· 4 min read
engineering leadership, agentic systems, team building, ACE
Building agentic systems isn’t only a technical challenge; it’s also a leadership and org challenge. Here are a few things that have helped me when leading teams that ship agents and automation.
1. Decide what “good” looks like before scaling
Before you scale an agent (or an agentic workflow), agree on what “done” and “good” mean: accuracy, safety, latency, human oversight. Without that, you’ll either over-polish or ship something that’s not ready. In our ACE work, we use phase goals and verification criteria so that “phase complete” is testable and shared across the team.
2. Clarity on who owns the agent’s behavior
Agents that touch real users or real systems need a clear owner: who is accountable for their behavior, their tools, and their limits? That’s not always the same person who wrote the first prompt. Defining ownership early avoids “it’s the model’s fault” and helps with incident response and iteration.
3. Technical decisions need to be explainable
Stakeholders (and sometimes regulators) will ask why the system did X. If your architecture is a black box even to the team, explaining it to others is hard. We try to keep decision records (e.g. ADRs) and audit trails so that we can say “this step ran because of this rule / this tool result” without hand-waving.
4. Hire and grow for “builder-leader” mindset
Agentic systems blur the line between “someone who codes” and “someone who designs and owns outcomes.” I look for people who can ship but also reason about impact and communicate trade-offs. That “builder-leader” profile — comfortable with code and with stakeholders — fits agentic work well.
These reflections come from leading engineering and coordinating ACE/Claire AI development. More on tech strategy, hiring, and org design in future posts.