Working The Way Agents Work

Working The Way Agents Work

The Vision describes what good looks like. This Journey is about how you get there. Let’s zoom into the second of the three shifts in perspective that the Vision sets out: work the way agents work.

Most organisations have deployed copilots, chat tools, maybe autonomous agents. More code is appearing. But throughput, learning speed and trust have not improved in proportion. The Vision describes this as an Engel’s Pause: the capability exists but the reorganisation has not caught up. Deploying AI tools does not, by itself, change the operating model. And the operating model is where the constraint sits.

In a human-led operating model, the classic constraint triangle is time, cost and quality. In an agentic operating model, those constraints are restated: execution time (how long the agentic system takes to complete a unit of work), token cost (how much inference the work consumes) and autonomy horizon (how long the system can continue producing trustworthy work before human intervention is required). Quality is embodied in the autonomy horizon; it ends when the work can no longer be trusted. Human-in-the-loop steps become constriction points that shape delivery flow.

The practical question for any engineering leader is to model how organisation matures in its journey to Agentic Development Lifecycle. Or to put another way, where is the binding constraint moving to next?

Stage 1: DevX as Supervisor

This stage is not about productivity. It is about building the expertise that everything else depends on: effective prompting, failure recognition, validation practices. Teams should expect to pay an innovation tax here; some effort goes into experimentation and dead ends, because those are the costs of learning a new way of working.

What signals ready to exit: shared context. When agents have the right information at the right time, supervision overhead drops and the constraint migrates to validation.

Stage 2: DevX as Review

The developer engineers the environment where agents succeed. Focus shifts from supervising output to managing context and guard rails. Agents verify other agents’ work. Humans review outcomes rather than implementations. The constraint shifts to validation: developers spend less time writing code and more time verifying that agent output meets requirements and integrates correctly.

Context engineering becomes a primary discipline: curating a layered hierarchy that combines organisational standards, project knowledge, task intent and model memories. Guard rails codify what used to live in reviewer judgement. Agent definitions become code, versioned and testable. Agent operations becomes a discipline.

What signals ready to exit: risk classification and multi-agent orchestration. When validation is trustworthy, the constraint migrates again — to intent specification.

Working the way Agents Work: Context Engineering

Context engineering is the art of delivering the right context at the right time. Too much context overwhelms the agent. Too little produces poor results regardless of model capability. The Stage 2 shift is that context stops being improvised and individual, and becomes layered, shared and governable.

In practice, that usually means moving from one-off prompts towards a context hierarchy that combines external best practice, organisational standards, project knowledge, task intent and controlled access to live systems.

Stage 3: DevX as Orchestrator

The developer describes intent and validates achievement. Multi-agent swarm and hive patterns coordinate complex work in parallel. Risk-based oversight scales human involvement with actual risk. The constraint is now intent specification: ambiguous intent produces unpredictable results at scale. When agents can execute reliably, the quality of what you ask for becomes the binding constraint.

Working the way Agents Work: Ceremonies to Flow

The agile paradigm was designed for two-week human coordination cycles. Sprint planning, daily stand-ups, sprint reviews and retrospectives assume that work moves in batch, that coordination is synchronous, and that the same people who plan the work also execute it. That last assumption is the one that breaks first. When agents execute the development work, the question is not “how do we run the same ceremonies faster” but “what do humans need to decide, and what do agents need to know?”

The replacement is not a faster version of the same activities. It is a separation into two distinct layers: an intent layer where humans define what problems matter, what outcomes to pursue and what constraints to elevate; and an execution layer where agents sequence, prioritise and coordinate their own development work within the boundaries that intent sets. Each layer needs its own framework. Forcing both through the same ceremony conflates strategic decisions with implementation logistics.

AgentOps for New Failure Modes

Failure-mode safeguards matter because agents fail differently than humans. Traditional technical failures are often visible and caught quickly; the harder problems are metacognitive. Agents can stop too early, lose the thread of the task, repeat failed actions, navigate badly, or verify work poorly whilst sounding confident. The implementation challenge is therefore not only to test outputs, but to build systems that make agent processes more dependable. This is a job for the new AgentOps.

AgentOps for Agentic Service Management

Operationalising this requires engineering discipline: making agents buildable, testable and deployable. The framing that ops departments become “an HR function for AI agents” is insufficient; there’s more to it than onboarding, monitoring, and finally retiring agents. AGSM must build the structure as well: the governance model, the trust infrastructure, the supply chain assurance and the knowledge systems that make autonomous agents operationally defensible. This is also a job for the new AgentOps function.

The Redesigned System

The promise of agentic software development is real, but the lesson of this Journey is that faster code generation is not, by itself, the transformation. The real change is redesigning the system around it. If agents can write a limitless amount of code, the question is not how to produce even more. The question is how to decide what is worth building, how to verify it, and how to keep learning where the next constraint will appear.