Agents Are Looking Inward. The Work Is Outward.

Introduction

I spent May and June on sabbatical—travelling, reading, and deliberately not shipping anything. The point of stepping back is to see the shape of a thing you're too close to when you're inside it. And the shape I kept seeing is this: nearly everything we're building for agents right now points the agent inward. At itself. At its own tools, its own context, its own memory. Very little of it points outward—at the people and the organizations the agent is supposed to be working for.

That sounds abstract, so let me make it concrete with the discipline that has absorbed the most energy this year: context engineering. It's a genuinely useful idea. It's also, when you look at it squarely, entirely inward-facing—and I think that tells us something about where the field's attention is, and where it isn't.

The argument, compressed: context engineering—for all its value—is the clearest symptom of the inward gaze; "do the work" is one stage out of five, and the coding-agent reflex fixates on it; and every way we already capture how work is done—SOPs, BPMN, process mining—gets bent toward executing a step instead of understanding the job.

Context engineering is provisioning, not understanding

Context engineering is the successor to prompt engineering, and the upgrade is real: instead of fussing over a single prompt, you manage the whole information environment an agent sees across a long, multi-step task—system instructions, tool definitions, retrieved data, memory, and the running history of what it's done. The failure it fights is context rot: the window fills with noise, the signal gets crowded out, and the agent's decisions quietly degrade. MCP is the plumbing that standardizes how all of that gets pulled in. This is good engineering, and if you're building agents you should be doing it.

But notice the direction every one of those knobs points. Tools, instructions, retrieved data, memory, history—all of it is about what the agent holds in front of itself. It is provisioning. We are getting very good at packing the agent's backpack. None of it—not one part—is about how the people around the agent actually do the work it's stepping into.

Every knob context engineering offers points at what the agent holds. How the work actually gets done—people, handoffs, what “done” means, judgment—sits outside the backpack, and most of it was never captured at all.

Context engineering answers "what should the agent have in front of it?" It does not answer "how does this work actually get done here, and where does the agent fit?" Those are different questions, and only the first one is getting attention.

Outward means knowing how the work gets done here

Here's the contrast that made it click for me. Context engineering can tell an agent that a close-the-books tool exists, hand it the ledger, and give it a crisp instruction. What it can't tell the agent is how the monthly close actually runs in this finance team: that the accrual review is really a negotiation with three department heads, that "done" means the controller is willing to sign, that the one number everyone actually watches isn't in the system of record. That's not context in the token sense. It's an understanding of the work as people do it.

Outward means the agent orients to that—to the shape of the work in the organization—rather than only to its own equipment. It's the difference between a well-prepared new hire who still doesn't know how anything really gets done here, and a colleague who does. We have poured enormous effort into the backpack. We have spent almost none on teaching the agent the job.

Work has stages; agents obsess over one

When I try to draw the work itself—not the agent, the work—it keeps coming out as a handful of stages. This is rough, and I'll tighten it later, but the cut I keep landing on is:

• Define how the work is to be done
• Define the work to be done
• Do the work
• Verify the work is doing the work
• Verify the impact

Now look at where the agent world spends its attention. Overwhelmingly on do the work. Coding agents are the loudest example: the whole contest is about generating the artifact. But for the people who own the work, "do the work" is one stage out of five, and often not the one that decides whether the outcome was any good. An agent that only knows how to do is blind to the four stages around it—how the method was decided, how the work got scoped, whether the result conforms, whether it actually moved anything.

Where agent-world attention concentrates (illustrative). The middle stage looks most like “a task an agent performs,” so it gets the tooling; the four stages around it are really about how people work, and stay neglected.

This is the same inward pull, one level up. We optimize the stage that looks most like "a task an agent performs" and we neglect the stages that are really about how people work—because those don't reduce to a tidy tool call. To be useful across the whole arc, the agent has to understand how humans do each of these stages, not just how to execute the middle one.

Every capture we have gets bent toward execution

We are not starting from zero. Enterprises have been trying to capture how work is done for decades, and the artifacts are sitting right there. Three of them are worth naming, because each gets close and each stops short.

The oldest is the Standard Operating Procedure: the written-down version of how a task is supposed to go. The trouble is that most of how work actually gets done was never written into one—it lives as tribal knowledge in the heads of the people who do it—and where SOPs do exist, they were written for humans and auditors, not for an agent to read. There is a live effort to fix exactly this: turning SOPs into explicit, testable, agent-executable procedures (some people are calling them agent operating procedures). It's the most direct attack on the capture problem I can find.

Then there is BPMN—Business Process Model and Notation—the formal one. A BPMN diagram is a rare two-in-one: a picture any stakeholder can read and, at the same time, an XML specification an engine can execute. It's already being used to orchestrate agents, bots, and people through a single governed process. But BPMN captures the flow—the boxes, the handoffs, the deterministic skeleton. It says little about the judgment inside the ambiguous boxes, which is usually where the real work is.

And process mining comes at it from the other end, discovering how a process actually runs—exceptions and all—rather than how the diagram says it should. It's the closest thing we have to an honest map of how people do the job.

Notice the pattern. The moment agents enter the room, every one of these gets bent toward execution: SOPs become automation logic, BPMN becomes an orchestration engine, process mining becomes a context feed. All three ask "how do we get the agent to do the step." None quite asks "how do we give the agent an understanding of how this work is done, so it's useful across the whole arc."

And underneath all of it, the largest share of how work really gets done is still uncaptured—never written, never modeled, never mined. You can't point an agent at what nobody wrote down.

The constraint isn't context. It's capture.

I don't have this fully worked out—that's the honest state of it after two months of turning it over. But it reduces to one sentence I'm sure of: we need to capture how work in the enterprise is actually done—across the whole arc, in a form an agent can understand and inhabit, not just execute.

That's the outward turn, and it's a harder problem than context engineering, because it can't be solved by pulling more of the right tokens into the window. SOPs, BPMN, and process mining are the start of it, but each captures a slice and each gets pulled toward automating a step. What we're missing is a representation of the work as people perform it—how the method is set, how the work is scoped, how it's done, how it's checked, whether it mattered—that an agent can actually use. Valuable as the inward optimizations are, they're hitting diminishing returns while this sits almost untouched.

Two follow-on questions have been eating at me since. Where in that arc can an agent actually own the work, and why does it stop where it does—I took a run at that in The Tideline. And once you've captured a procedure, how do you get an agent to discover and apply it on its own, unsupervised—which turns out to be what a skill is for, and we put it to the test here. But the root of both is this one: we built agents that look inward, and the work—how it's really done—is still outward, still mostly uncaptured.