From Instructions to Intentions
For a while, the standard move when building an AI workflow was to write out every step. Get this URL. Parse that JSON. If the field is empty, try the fallback. The more complex the task, the longer the instruction set — and the longer the instruction set, the more time a team spent maintaining prompts rather than improving outcomes.
That model is starting to show its age.
The shift is subtle but consequential: rather than telling an agent how to complete a task, the more productive approach is to describe what a successful outcome looks like and let the agent work out the path. It is the same move software engineering made decades ago when it shifted from procedural to declarative programming. SQL does not tell the database which rows to scan in which order; it describes the result set it wants and the database figures out the execution plan. The same logic applies to agents. When a workflow is expressed as an outcome contract — “produce a regulatory-compliant model documentation file that covers these four sections, passes internal review, and cites these data sources” — a capable agent can find the path. Spelling out every intermediate step does not add precision; it removes flexibility and leaves intelligence unused.
What Declarative Looks Like in Practice
The concrete version of this idea involves writing contracts in plain markdown: goal declarations, output specifications, sub-agent assignments, tool constraints. The agent (or a meta-agent layer sitting above it) reads the contract and determines the execution path. No deployment artifacts, no scaffolding code — just text files that describe what done looks like.
This approach has a few properties worth noting.
It composes. Contracts can chain — one agent’s output becomes the input to the next contract. Fan-out (multiple agents working in parallel), adversarial review loops (one agent produces, another critiques), and map-reduce patterns all emerge naturally from contract composition, without writing a single line of orchestration code.
It separates exploration from production. The first run against a new contract might use a large, expensive model to find a good execution trace. Once that trace proves out, it can be codified into a more procedural specification and replayed cheaply on future runs. The expensive model earns its cost on the discovery pass; cheaper models handle the repetition.
It stays on-premise when it needs to. For organisations with strict data policies — financial institutions, regulated industries — a declarative workflow that runs on an approved internal model, triggered by a webhook, never ships data to an external lab. The operational knowledge lives inside the organisation as a collection of plain text files.
The Real Bottleneck Is Expressing Intent
The argument underneath all of this is that the infrastructure layers — context management, harness tooling, model capability — are now “solved enough” for many practical use cases. The remaining bottleneck is not cleverer prompting or faster inference. It is the clarity of the intent specification.
That reframe matters. It shifts the problem from engineering (how do we make the agent do this?) to design (what does success actually look like?). Those are different skills, and in many organisations the people who know what success looks like — product managers, compliance officers, domain experts — are not the ones currently writing agent instructions.
A contract-based interface lowers that barrier. “A grumpy senior developer who hates AI-generated code should review this pull request and flag anything that looks like it was written by a model” is a complete workflow specification. An agent can turn that into a deployed webhook job. The person who wrote that sentence does not need to understand sub-agent routing.
Known Limits
This approach is not without friction. Model quality variance is real: the same contract behaves differently on a small model compared to a frontier one, which means contracts cannot yet be written as truly model-agnostic. Self-reported completion — an agent declaring it is done — is also not fully trustworthy, which pushes verification responsibility back onto the framework.
Classifier models as lightweight contract verifiers look like a promising answer: a cheap, fast model checks whether the output actually satisfies the contract before the job is marked complete. That separation — a generator and a verifier each optimised for its role — mirrors patterns that have held up well elsewhere in the AI stack.
Where This Points
The longer arc is that as models become more capable, the optimal instruction set gets shorter, not longer. Detailed step-by-step prompts were sensible when models needed hand-holding through every decision. As judgment improves, over-specification becomes the bottleneck — it forces a capable agent to follow a suboptimal path when it could find a better one.
The practice that holds up is learning to resist the impulse to specify the how. Describe the outcome, define what done looks like, and let the agent earn its capability.
Text summarized and optimized using Anthropic’s models and reviewed by a human.