A surprising amount of AI disappointment is self-inflicted. If you want an AI teammate to be useful, treat onboarding as a systems problem. Standards, context, access boundaries, and escalation paths will do more for performance than one heroic prompt written at 1 a.m. and subsequently treated as sacred scripture.
The wrong debate
The wrong debate is whether the agent is smart enough in the abstract. The useful question is whether it has actually been onboarded into your way of working.
This framing matters because it drags the conversation back to the workflow. When teams under-specify the work, they do not remove uncertainty. They merely send it downstream, where it returns wearing the more expensive costumes of rework, second-guessing, and inconsistent output.
A human junior gets examples, naming conventions, escalation paths, and the awkward local rules nobody thought worthy of the architecture diagram. A synthetic junior needs the same categories of help, except they must be packed into artifacts rather than delivered through hallway conversations and knowing glances.
This sounds obvious, yet teams miss it constantly because the missing pieces are not glamorous. A clear standard, a useful example, a scoped permission, or a crisp definition of done rarely wins the demo. They do, however, win the week.
What actually matters
When teams say an agent is unreliable, they are often describing terrible onboarding. A human teammate gets a repo tour, examples, naming conventions, escalation rules, and the awkward bits nobody writes down until somebody breaks one. The model gets a prompt and some atmospheric optimism. Everyone then acts surprised when it behaves like a contractor lowered into the codebase through a skylight.
If you want better output, start by making the work environment legible.
Standards are not bureaucracy here. They are compression. A short, explicit set of conventions lets the agent spend tokens on the task instead of repeatedly discovering how your team names files, structures tests, or documents migrations. Standards feel less exciting than model demonstrations because nobody has yet found a thrilling way to unveil a naming convention onstage. Boring clarity wins anyway.
The debate also gets trapped in prompt phrasing. What matters more is whether the agent can see the local truth: architecture notes, examples of good changes, known landmines, recent decisions, and the actual shape of the task. Context is not decorative seasoning sprinkled over a prompt. It is the difference between asking for help from a teammate who knows the system and one who has just arrived from another planet with repository access.
If I were fixing this tomorrow, I would not begin with a new model. I would begin by making the work easier to delegate: clearer context, cleaner standards, safer permissions, and better checks. Once those exist, model upgrades start to matter more.
What scales is not a clever one-off prompt but a reusable control surface: shared standards, reusable context, bounded permissions, visible examples, and inexpensive checks. Once those are in place, a stronger model helps. Before they exist, model upgrades mostly rearrange the disappointment and improve its typography.
The useful question is not whether the agent can do something in principle. It is whether the task has been defined clearly enough, instrumented cheaply enough, and bounded safely enough to be delegated in the first place.
A workflow I would actually trust
One workflow I like is a small context pack beside the work: a task brief, repo map, relevant files, coding standards, definition of done, risky surfaces, and examples of good output. The agent gets that package every time. Humans do too. The result is fewer clarification loops and less strange improvisation, because the system no longer has to infer what the team meant but neglected to write down.
A decent onboarding pack for an agent looks boring in exactly the right way: a short statement of responsibility, a repo map, a definition of done, a list of risky surfaces, examples of acceptable changes, and explicit escalation rules. Give that package to a model and to a new teammate and both should ask fewer confused questions.
The interesting part is not merely that the agent improves. It is that the team has finally documented what it claims to value.
This is also why onboarding and governance are closer than they appear. Once permissions, expectations, and failure paths are explicit, trust becomes operational rather than emotional. You are no longer hoping a synthetic teammate behaves itself because the prompt sounded stern. You are shaping the conditions under which useful behaviour is more likely and costly mistakes are easier to catch.
Measurement matters because teams are remarkably good at narrating improvements they have not checked. I would track at least five things: time to a usable first draft, number of clarification loops, amount of human cleanup, defect or regression rate after merge, and how often rollback or rework was required.
Those numbers are boring. That is precisely why they are useful.
They also prevent a common trap. An agent can feel fast because it produces a large quantity of text or code quickly while making the total loop slower once review, debugging, and cleanup are included. If the workflow is supposed to ship, the metric must sit closer to the shipped outcome than to the charisma of the demonstration.
Why this is credible
This framing aligns with public engineering guidance from Anthropic, which has argued that successful agent systems are usually built from simple, composable patterns rather than ornate frameworks, and that context engineering becomes a more useful frame than prompt engineering once agents enter real workflows. NIST arrives at a similar destination from the governance side: trustworthiness comes from lifecycle controls around the system, not from model confidence alone.
A useful agent is not the model you bought. It is the workflow you bothered to build.
The public evidence base is not perfect, but it points in a consistent direction. Anthropic’s engineering writing has repeatedly emphasised that effective agents depend on simple, composable patterns, strong context, and well-designed tools rather than prompt theatrics alone. Its newer work on harnesses reinforces the same lesson for longer-running tasks: the surrounding workflow determines whether capability survives contact with reality.
That sits comfortably beside NIST’s risk-management framing, which treats trustworthy AI as a systems problem, and beside the DORA and METR findings that warn teams not to confuse subjective speed with shipped value. I would not overstate any single study. Taken together, however, the case for better harnesses is considerably stronger than the case for endless prompt superstition.
The objection that sounds smarter than it is
A common objection is that all this structure slows people down, and that the real winners will simply use more capable models more aggressively. I think that gets the timing backward.
Loose workflows can feel faster at first because they externalise ambiguity onto later review and cleanup. The first draft arrives quickly. So do the missing assumptions, inconsistent decisions, and senior engineer quietly wondering why the same problem has returned with fresh formatting.
Structured workflows feel slower only until the same task appears for the fifth or fiftieth time.
That is when the boring scaffolding begins to compound. The brief exists. The examples exist. The checks exist. The team no longer spends senior attention rediscovering the same missing assumptions. Good harnesses are not anti-speed. They are how speed survives contact with scale.
Where I would start this week
If the thesis of this article is right, the first move is not a larger model budget. It is one cleaner delegation lane. Pick a recurring task and make the surrounding expectations unambiguous enough that both humans and agents can run it in the same way.
Choose one recurring task with a clear business owner and a low-to-moderate blast radius.
Write a reusable task brief covering the goal, scope, relevant files or context, and definition of done.
Add one or two examples of acceptable output and one explicit escalation rule for uncertainty.
Measure re-asks, human cleanup, and whether the task actually ships more smoothly after the change.
The point is not to create a sacred process document that future employees must interpret by candlelight. It is to make one useful loop more legible, more repeatable, and easier to trust. If that feels slightly boring, good. The boring version is usually the version that ships.
Notes
Anthropic (2024), “Building effective agents,” published December 19, 2024.
https://www.anthropic.com/research/building-effective-agents
Anthropic (2025), “Effective context engineering for AI agents,” published September 29, 2025.
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
Anthropic (2025), “Effective harnesses for long-running agents,” published November 26, 2025.
https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
Anthropic (2025), “Writing effective tools for AI agents—using AI agents,” published September 11, 2025.
https://www.anthropic.com/engineering/writing-tools-for-agents
NIST (2023), “Artificial Intelligence Risk Management Framework (AI RMF 1.0),” NIST AI 100-1.
NIST (2024), “Artificial Intelligence Risk Management Framework: Generative AI Profile,” NIST AI 600-1.
Google Cloud / DORA (2025), “How are developers using AI? Inside our 2025 DORA report,” published September 23, 2025.
https://blog.google/innovation-and-ai/technology/developers-tools/dora-report-2025