At SmaariX, the work in front of us was sized for a larger organisation, and closing the gap by hiring was not the option on the table. Agents took on a substantial part of the engineering execution.
My job was to decide which work I was willing to delegate and what I needed back before I could accept it. I was also doing the work around that delegation: extracting requirements, writing specifications, building and reviewing results. When an assignment was unclear, I was often the person who had to repair it.
That made some familiar management problems difficult to ignore.
Clarity starts before the instructions
A detailed specification can still leave the important questions unanswered. What outcome do we need? Which decisions can the agent make? What must it leave alone? What would count as completion?
A capable person may fill gaps by asking questions, drawing on experience or understanding the organisation. An agent may fill the same gaps with a plausible assumption and continue. That makes implicit context expensive.
I now put more care into naming the exact files, acceptance criteria and boundaries of a task. It has improved the assignments I give people too. Much of what I once treated as shared understanding was something I had not yet decided clearly.
Good people still need room to exercise judgment. Clear direction gives them that room without making them guess what success means.
Three parts of delegation
I keep coming back to specification, authority and verification.
- Specification
- Define the work and what will count as done.
- Authority
- Set the limits of what the delegate may do.
- Verification
- Decide what evidence must come back with the result.
Specification describes the work and the context needed to do it. An outcome alone is not enough if the person or agent receiving it has to invent the constraints.
Authority defines which decisions and actions have actually been delegated. The rule I use is familiar from payment systems: a delegate cannot receive authority the delegator does not hold. The grant has a scope and an end. “Own this” needs to mean something more precise than “do whatever seems necessary”.
Verification determines what must come back with the result. A report that work is complete is useful information, but it is not sufficient evidence on its own.
Agents shorten the feedback loop on all three. A weak assignment can produce the wrong result quickly, leaving me with a concrete example of what I failed to make clear.
The mistake I made with verification
I let the agent that did the work also tell me the work was done.
It felt efficient. The implementation and the checks came back together, in one place. But I had created a closed loop: the same party produced the work and the evidence used to accept it, with no independent review between them.
I had worked for years in environments where separation of duties mattered. I still built this arrangement, because it looked like a convenient status update.
The rule I run now is explicit: an implementer never certifies its own assured work. It is written into the contract every session loads, so it does not depend on me remembering to ask for another check.
The implementer can still test its work and report what happened. For work that requires independent assurance, that report is an input to acceptance. It does not close the decision.
Where trust works differently
With a person, trust built over time is a legitimate reason to check less often. They have continuity, a reputation and responsibility for what follows. Recognising that is part of good management.
I do not treat an agent’s previous correct answers as the same kind of trust. The next result still needs the evidence appropriate to its consequences. Otherwise, familiarity becomes a reason to relax the very control I put in place.
This does not mean inspecting every trivial action with equal intensity. It means deciding what assurance the work needs and keeping that decision separate from how reassuring the output sounds.
There are also decisions I would not delegate: what to build next, what to stop, which constraint is real and whether a disagreement is technical or about something the team has not said aloud. Those need someone who understands the situation and will live with the outcome.
What this suggests about the team
I am not arguing that an engineering function needs fewer engineers. My experience is that agents expose the parts of management that depended on people quietly compensating for a weak process.
The work also keeps bringing me back to two complementary capabilities. One is building within the customer’s real environment, including its inconvenient constraints. The other is reading that environment: understanding the workflow, finding the requirement nobody has written down and turning it into something buildable.
I would plan around that pair: someone who can deliver within the environment, and someone who can turn its operational reality into clear requirements. I would not assume the second capability arrives automatically with the first. Technical execution alone cannot tell me whether we understood the problem.
As agents take on more execution, I place more value on that ability to understand the situation. The people who can uncover what matters, make a sound decision and explain it to others become more important to the work.
What I changed
Working with agents has made me more precise about assignments and more careful about acceptance. The useful lesson was not a new way to write a longer prompt. It was recognising where I had allowed convenience to stand in for judgment.
The rule I return to is the one I learned the hard way: doing the work and deciding that it is ready are separate responsibilities. I want the way we work to preserve that separation, even when combining them would be faster.