By 2027, 74% of companies are expected to use agents in some capacity, according to a recent Deloitte study. For years, we’ve designed and built software to improve the human experience of navigating our apps, websites, operating systems, and documents. Now, the user isn’t a human at all. This has broader implications beyond shifting from dashboards and the controlled workflows we design for human tasks. We are in a moment where we need to design agents’ operating environments, while also designing human workflows to effectively guide the agent experience within these environments.
We are still early in our learning on what agents actually need from us to be repeatably, reliably successful. The instinct is to treat agent integration purely as a prompting or UI problem. Designing a well-governed execution environment is new ground for us as a culture. However, the underlying principles of good design and good management haven’t changed: we owe agents clear context, unambiguous direction, and explicit intent.
Context: Why Coding Came First
Context is arguably the most important input if we want agents to repeatably deliver at the level we intend. Software development has more of it recorded than almost any other field: repos, API schemas, the relationships between systems, code review and community discussions. So it makes sense that AI frontier labs started with coding. It’s one of the few domains where a good bit of context is already written down.
But as any new hire on a software team will tell you, even with all that data, agents will still lack the institutional memory embedded in the unwritten rules no one ever documented. That gap is widespread: 43% of developers are concerned that AI tools lack sufficient context about their specific project or codebase. Tacit knowledge spans everything from everyday conventions, like preferred libraries for specific tasks, to high-stakes operational ghosts: a late-night hotfix that hangs around forever, or a seemingly empty database column that secretly underpins a custom revenue report. This context lives in a senior engineer’s head, a recent Slack thread, or nowhere at all. It is rarely in the codebase itself.
If this is true in software, one of the best-documented fields, it’s easy to see why agents struggle to perform effectively from day one in many other industries. In healthcare and law, much of the institutional knowledge that shapes day-to-day work is learned and internalized. It lives in people’s experience rather than in formal documentation. A legal agent may not know a particular partner’s preferred structure, tone, or argumentation for a brief, while a healthcare agent may not understand the local workflows and escalation practices a busy clinic uses to support clinician-led triage. Documentation alone cannot close that gap, because the challenge is not simply access to information; it’s the transfer of context. To give agents what they need to succeed, we have to onboard them much as we would a new hire.
Direction: Why Osmosis Doesn’t Work
Onboarding a new teammate requires more than providing the proper materials and access. When we are invested in the success of those around us, we provide solid direction on what to do with the new materials and access: expectations, clarity on what we’re trying to achieve, and feedback along the way. I bring this same mindset to designing for agents. I give clear, specific direction (relative to the task at hand). That holds for any teammate, regardless of their tenure. Still, in a new hire scenario, direction must go further, because they don’t yet carry any institutional context.
Think of an agent as a new hire who never stops being new. It’s eager and capable (and frankly, has boundless energy), but it can’t pick up and retain as many of the unwritten rules the way a person does over time. Humans learn through osmosis and experience, while agents learn from architecture that is explicitly built into their working environment.
With a new hire, you can close that gap over time with questions, feedback, and new insight they pick up about the organization’s processes and preferences along the way. Literal coffee machine chats or team lunches. With an agent, you have to build that gap-closing into the design itself. This can include:
- Giving the agent a structured context window that separates durable rules, task-specific facts, and relevant history, rather than dropping a pile of documents into its lap.
- Defining its permissions and decision boundaries up front: what it may do independently, what requires approval, and what it must never access.
- Embedding a few concrete examples of strong output directly in the experience, so the agent has a clear model for how the work should be done.
- Sharing previous dead-ends that you’ve hit.
Designing a well-governed agent environment isn’t about making work easier for the model. It’s about protecting the human engineering team from invisible technical debt. But even a well-directed agent can follow instructions perfectly and still miss the point. Direction tells it what to do, but it doesn’t tell it what “good” looks like. That gap is where intent comes in.
Intent: Why Agents Drift to The Middle
It’s important to remember that agents are pattern-matching machines, trained on massive quantities of knowledge and naturally inclined to deliver the statistical average. Without clear, explicit intent, that average output is exactly what an agent will bring back. Ask an agent to “add a user authentication endpoint,” and it will generate a textbook Express route with basic password hashing. It works, but it completely ignores your team’s custom auth service, skips required telemetry, and breaks your standardized error formatting. It’s an adequate feature on paper, but depending on the context, it’s an architectural bug in practice. The ease with which “bugs” like this are introduced cannot be overstated.
To prevent this, direction must be paired with active intent verification and logging. Guardrails shouldn’t just check whether the code compiles, though this is important. Guardrails must explicitly enforce the opinionated standards, edge-case rules, and domain context that elevate generic output into production-ready work. Logging matters as a system status indicator for us humans. This traceability is critical for trust.
In human interactions, there’s a lot of space for uncertainty. Someone can share a first version with you, and together you can talk through what’s strong and what needs improvement. This works because we don’t expect our human co-workers to be autonomous machines. To truly capture the power and promise of agentic coworkers (who we do need to run more autonomously…), we can engineer many of these directional checks. The back-and-forth still needs to happen, but it can’t fall entirely on manual effort. By front-loading clear acceptance criteria and verification rules, you enable the agent to run its own internal feedback loops. Designing for error prevention is another sound UX principle we can apply in this new world: giving agents the ability to flag low confidence before committing to an action, rather than silently defaulting to a best guess.
Where the Metaphor Breaks
The new-hire framing works, until it doesn’t. With a human hire, experience begets competence which begets judgment. Watching your new hire internalize the “why” behind context and direction is what builds trust over time, and in general, this is cumulative. An agent has nowhere to accumulate and store this experience.
A new hire’s first week and hundredth week look different. An agent’s first task and thousandth look identical, unless you design and build something to make them different. This is our new design challenge.
Agent Responsibility Hinges on Design
If responsibility can’t live in the agent, it must live in the scaffolding around it. It comes down to the same three questions I’d ask before handing work to any new hire: What context do they have? What direction have I given them? What’s my actual intent?
The next time you hand a task to an agent, don’t just check the output. Check your own inputs first. Did you give it the context a new hire would need on day one? Was your direction specific enough to survive being taken literally? Was your intent clear enough that “the median answer” wasn’t the best it could do?
With this clear guidance in hand (in byte?), something interesting happens: an agent doesn’t need a long runway to become trustworthy. The context, direction, and verification you build in up front define how it operates on every task. A new hire earns your trust over time; an agent has to earn it each time through the system you designed. Responsibility isn’t something it grows into, it’s built in from the start. The question isn’t when your agent will be ready for more responsibility. It’s whether you designed it to earn that responsibility on every single task.
