I have spent years learning to draw process diagrams. The good ones are deceptively hard. You are not decorating boxes, you are making an argument about how work flows, where it breaks, and who owns the call when it does.
Last week I asked an agent to draw one for us. Not a toy example. The real thing: our own engineering process, the way we build Arqadia, the AI-native system we are building to run our own firm. Valid, properly styled, the kind of artifact I would have blocked out an afternoon for.
It got it right. Not perfect on the first pass, but right enough that I could sit with it and refine it in conversation, the way I would with a sharp colleague. It drew the process the way I picture it in my head.
Here is the part worth sitting with. It did not work because the model is brilliant, though it is. It worked because the agent had been onboarded.
Onboarding, not adding
The default story about AI is additive. You add an agent to a task and the value shows up. That story is why so many capable-looking pilots underwhelm.
The better story is that you onboard an agent, the same way you onboard a person. Before that diagram was possible, three things were true:
- Access. The agent could reach the systems and files where the work actually lives.
- The right capabilities. It had what the task specifically called for, not just a general model.
- Correct context. The knowledge it needed was codified and correct, including our own internal documentation about how we build.
Take any one of those away and the same capable model can produce something confident and wrong. I have watched the context version of that happen. Earlier in the build, before we had locked our terminology, the model quietly adopted its own vocabulary, overloaded it, and reasoned its way into an analysis error. Same model. Muddled context. Bad result.
What would a capable new hire need to do this job, and has the agent been given the equivalent?
The gating variable was not the model. It was whether the context was correct.
Why the bar is higher, not lower
The tempting assumption is that an agent needs less setup than a human, because it is software. My experience is the reverse.
A new hire is robust. Hand them an ambiguous brief and they ask a question, read the room, remember last week, and fill the gaps with judgment. An agent is brittle by comparison. It does not reliably ask, it does not carry context you did not give it, and its memory is shorter than you would like.
So the enablement a person does quietly, in their own head, you have to make explicit for an agent. Onboarding an agent is more deliberate work than onboarding a person, not less. That is the uncomfortable center of this.
What this is not
I want to be careful about the boundaries, because this argument is easy to misread.
It is not a claim that AI is overhyped. The opposite. The ceiling is high, higher than most of us are using. The point is that you reach it through enablement, not despite it.
It is not an argument for a heavy governance bureaucracy. Onboarding means access, codified knowledge, and a human who owns the output. It is not a committee.
And it does not apply everywhere. For narrow, self-contained tasks with clean inputs, adding an agent already works fine. This is about the judgment-laden work that runs on your organization's own knowledge, which is exactly where the value and the difficulty both live.
Two fair objections deserve a straight answer. First, isn't this just good context engineering with a new label? No. It is about the unit and the ownership. This is an organizational onboarding problem, access, codified knowledge, correctness, and a human owner, not a prompt trick. Second, isn't codifying all that knowledge the overhead AI was supposed to remove? It feels like it, right up until you notice the codified context is the leverage. The diagram was possible because that context existed, and the same context compounds across every future use.
The honest counter is the frontier itself. Memory improves, context windows grow, tool use gets better, and some of this onboarding burden will shrink. I think that is true. But even the best agent drew our process correctly only because the context was correct, and no model decides what is true in your business or grants itself access to your systems. Onboarding gets cheaper. It does not go away.
The quieter payoff
There is a personal coda to this. I spent years getting good at drawing those diagrams by hand. Watching an agent do it in minutes could have felt like a loss. It did not. It moved my attention from producing the thing to the more interesting questions: is this actually right, what does it miss, where is the nuance? The boxes got faster. The judgment got more valuable.
That is the shift worth designing for. Not agents instead of people. People freed to spend their attention where it counts, on top of agents that have actually been set up to succeed.
- A capable agent's usefulness is decided mostly by how well it is onboarded (access, the right capabilities, correct and codified context), not by the model or the prompt alone.
- The same model flips from impressive to wrong based on whether the context is correct. The context is the gating variable.
- Agents are more brittle than people, so their onboarding has to be more explicit, not less.
- This is enablement, not bureaucracy, and it is for work that runs on your own knowledge, not narrow generic tasks.
- The frontier will lower the onboarding cost over time. It will not remove your responsibility to grant access and codify what is true.
If you are deciding how to deploy agents and the results so far have underwhelmed, it is worth asking a different question before you shop for a better model: what would a capable new hire need on their first day, and has the agent been given the equivalent? If that is a live question for you, I am glad to compare notes.