Build Around the Agent, Not the API

For the first wave of AI products, the center of gravity was the raw LLM API.

You passed in a prompt. You attached context. You received text. Then you wrote the real system around it: retrieval, parsing, retries, tool calls, test execution, deployment logic, permissions, observability, and human review.

That made sense when the product was a chatbot, summarizer, or extraction pipeline.

It makes much less sense when the job is software engineering.

Software development is not a single text-generation event. It is a loop: understand the problem, inspect the repository, make a change, run the system, read the failure, revise the plan, test again, review the diff, and ship.

The unit of work is not a completion.

It is a verified change.

That is why the next serious AI engineering stack should not be built around raw model calls. It should be built around agentic coders: Codex, Claude Code, and the agent frameworks emerging around them.

The API is still there. The model still matters. But the abstraction that matters most is changing.

Old center: prompt -> model -> text
New center: intent -> agent -> tools -> feedback -> verified outcome

The mistake: treating software work like text generation

A raw LLM API gives you language.

Engineering needs action.

That gap is easy to underestimate. A model can suggest a patch, but an engineering system needs to know whether the patch compiles. It needs to run tests. It needs to see logs. It needs to compare screenshots. It needs to inspect traces. It needs to understand which files are safe to edit, which commands require approval, and which architectural boundaries must not be crossed.

When teams build directly on top of the raw API, they slowly rediscover all of this.

They start with a prompt.

Then they add tool calling, file access, shell execution, sandboxing, retries, repository memory, CI hooks, code review, issue-tracker integration, observability, permissions, and audit logs.

In other words, they rebuild an agent.

That is backwards.

Tools like OpenAI Codex and Claude Code already package many of the primitives that make software work agentic rather than conversational. Codex can read, edit, and run code, work in cloud environments, and create pull requests from repository tasks. Claude Code works directly inside the codebase across terminal, IDE, web, and Slack, with capabilities such as mapping codebases, reading issues, writing code, running tests, and submitting pull requests.

The strategic question is no longer:

How do we wrap an LLM API so it can code?

It is:

How do we build an engineering environment where coding agents can succeed repeatedly?

The new primitive: the coding agent as execution layer

The important shift is subtle but decisive.

In the old stack, the model was a component inside an application.

In the new stack, the agent becomes an execution layer inside the engineering organization.

That means the agent is not merely answering questions. It is doing work: opening files, editing code, running commands, validating behavior, producing artifacts, and escalating only when judgment is required.

This is the point OpenAI's Harness Engineering post makes so vividly.

The interesting part is not just that Codex was used heavily. It is that the team reorganized engineering around Codex. OpenAI says every line of the product's application logic, tests, CI configuration, documentation, observability, and internal tooling was written by Codex, and estimates that the product was built in about one-tenth the time it would have taken by hand.

But the deeper lesson is this:

Humans steer. Agents execute.

The team's job shifted away from directly writing code and toward designing environments, specifying intent, and building feedback loops that let Codex agents do reliable work.

That is the actual lesson.

Not "use Codex."

Not "replace engineers."

Not "prompt harder."

The lesson is:

Build the harness.

The harness is bigger than one example

OpenAI's Harness Engineering post gives the phrase a concrete example, but the pattern is broader than one product or one company.

A harness is the surrounding system that makes an agent effective. It gives the agent context, tools, boundaries, memory, tests, feedback, and permission to act.

It turns a powerful model into a reliable worker.

This is where many teams will either compound advantage or stall.

An agent without a harness is just a clever process with too much freedom and too little feedback. It can generate plausible code, but it cannot reliably know whether the work is correct, aligned, safe, or maintainable.

An agent with a harness can operate inside a loop.

It can inspect the current state.

It can make a change.

It can run the product.

It can read logs.

It can check tests.

It can see a failure.

It can revise.

It can open a pull request.

It can respond to review.

It can leave an audit trail.

That loop is the product.

The raw model call is only one part of it.

The research already pointed here

This shift did not appear from nowhere.

The ReAct paper showed that reasoning and acting should be interleaved: reasoning helps a model plan and handle exceptions, while actions let it interact with external environments and gather information.

Toolformer showed the same direction from another angle: models become more useful when they can decide when and how to call external tools.

Software engineering raises the stakes because the environment is large, stateful, and unforgiving.

SWE-bench was designed to test whether AI systems can solve real GitHub issues, using 2,294 task instances from 12 popular Python repositories. The SWE-bench paper argues that resolving these issues often requires coordinating changes across functions, classes, and files, interacting with execution environments, handling long context, and reasoning beyond traditional code generation.

SWE-agent pushed the idea further by arguing that language-model agents are a new kind of end user. Just as humans benefit from IDEs, agents benefit from interfaces designed around their needs. Its custom agent-computer interface improved an agent's ability to edit files, navigate repositories, and execute tests and programs.

That is the core principle:

Agents need ergonomics too.

Not human ergonomics.

Agent ergonomics.

A repository that is obvious to a senior engineer may be illegible to an agent. A tool that is easy for a person to interpret may return noisy context to a model. A dashboard that works for a human may be useless unless the agent can query the logs, metrics, and traces programmatically.

The future engineering stack will be designed for both humans and agents.

What changes when the agent is the center?

The architecture changes.

The workflow changes.

The role of the engineer changes.

When the raw API is the center, engineers write orchestration code around completions.

When the agent is the center, engineers build systems that dispatch work to agents, constrain agents, observe agents, and continuously improve the environment agents operate in.

That difference matters.

A raw-API workflow asks:

How do I prompt the model to produce the right answer?

An agent-centered workflow asks:

What would the agent need to inspect, run, modify, verify, and safely ship this change?

That second question leads to a better engineering organization.

It forces you to expose logs.

It forces you to improve tests.

It forces you to write down architecture.

It forces you to encode taste into linters.

It forces you to make undocumented tribal knowledge visible.

It forces you to turn review comments into reusable rules.

OpenAI's Harness Engineering post describes exactly this pattern: repository knowledge became the system of record, with a short AGENTS.md acting as a map rather than a massive instruction manual; deeper documentation lived in structured repository docs; and linters and CI jobs mechanically checked that the knowledge base stayed current and cross-linked.

That is a major conceptual shift.

Documentation stops being a human-only artifact.

It becomes executable organizational memory for agents.

The harness has five layers

An agent-first engineering system needs five layers.

1. Intent

Work should enter the system as a clear goal:

• Fix this bug
• Migrate this service
• Reduce this latency
• Add this feature
• Investigate this regression
• Improve this test suite

The human should define the outcome and constraints. The agent should own much of the execution.

Anthropic's research on Claude Code usage describes a similar division of labor: people make most of the planning decisions, while Claude makes most of the execution decisions. The same report argues that domain expertise amplifies the quality of agentic coding sessions.

That is the right split.

Humans decide what matters.

Agents do the mechanical work of getting there.

2. Context

Agents need the right context, not infinite context.

This means architecture docs, product specs, API contracts, database schemas, runbooks, test instructions, design principles, and known failure modes should live close to the code.

The goal is not to dump everything into the prompt. The goal is progressive disclosure: give the agent a map, then let it navigate to the relevant source of truth.

OpenAI reached this conclusion in the Harness Engineering project: anything the agent cannot access while running effectively does not exist to it, so important context must be encoded into repository-local, versioned artifacts.

This is one of the most important ideas in the entire post.

If the architecture only lives in Slack, the agent cannot use it.

If the product decision only lives in a meeting, the agent cannot use it.

If the debugging trick only lives in one engineer's head, the agent cannot use it.

Agent-first engineering turns invisible knowledge into visible infrastructure.

3. Tools

Agents need tools built for agents.

That includes:

• Shell access
• Test runners
• Browser automation
• Observability queries
• Issue trackers
• Pull request systems
• Deployment tooling
• Database sandboxes
• API clients
• MCP servers

The Model Context Protocol matters here because it standardizes how AI applications connect to external systems such as local files, databases, search engines, calculators, and workflows.

But tools are not automatically useful just because they exist.

Anthropic's guidance on writing tools for agents makes the key point: tools are contracts between deterministic systems and non-deterministic agents, so they must be designed differently from ordinary APIs. Effective tools need clear boundaries, meaningful context, token-efficient responses, and evaluations that measure whether agents can actually use them.

This is why "just give the agent all the tools" is not a strategy.

A good harness gives the agent the smallest useful set of tools, with crisp names, clear permissions, structured outputs, and real evaluations.

4. Verification

Agents need feedback loops.

Tests are the obvious loop. But serious agentic engineering needs more than unit tests.

It needs:

• Integration tests
• Type checks
• Linters
• Screenshots
• Browser traces
• Performance budgets
• Security checks
• Build logs
• Canary results
• Observability queries

OpenAI's Harness Engineering team exposed logs, metrics, and traces to Codex through a local observability stack for each worktree. That made prompts such as improving startup time or enforcing span latency budgets tractable because Codex could query signals, implement fixes, rerun workloads, and iterate.

This is where agentic coding becomes operationally interesting.

A human can read a dashboard and reason about a regression.

An agent needs an interface.

Once that interface exists, the agent can debug.

5. Control

Agents need boundaries.

The more useful an agent becomes, the more dangerous it becomes without controls. A coding agent can edit files, run shell commands, access secrets, call services, and change production-adjacent systems.

That makes permissions, sandboxing, network restrictions, audit logs, and approvals part of the product surface.

Codex uses sandbox and approval controls: the sandbox defines what Codex can technically do, while approval policy decides when Codex must ask before crossing a boundary. Claude Code takes a similar control-oriented posture with default read-only behavior, permission prompts, working-directory restrictions, and safeguards against prompt injection and unsafe commands.

This should be treated as architecture, not configuration.

Agent-first systems are security systems.

The role of the engineer moves up the stack

The fear around AI coding is often framed as:

Will agents replace engineers?

That is the wrong frame.

The more immediate change is that agents alter the leverage point of engineering work.

In a human-first workflow, a strong engineer personally writes, reviews, debugs, and ships a large amount of code.

In an agent-first workflow, a strong engineer designs the system in which many agents can write, review, debug, and ship code safely.

That means the most valuable work moves toward:

• Defining intent clearly
• Decomposing ambiguous goals
• Encoding architecture
• Improving tests
• Building agent-facing tools
• Creating reusable skills
• Tightening permission boundaries
• Turning review feedback into automated checks
• Making logs and traces queryable
• Designing evaluation loops
• Deciding when human judgment is required

This is not less engineering.

It is more systems engineering.

OpenAI's Harness Engineering post makes this point directly: as Codex took on more of the software lifecycle, the hard problems became environment design, feedback loops, and control systems.

That is where teams should invest.

Not in another prompt wrapper.

Not in another thin chat interface.

In the harness.

Skills, playbooks, and reusable agent workflows

Once agents become central, teams need a way to teach them repeatable workflows.

This is where agent skills, repository instructions, and workflow packages become important. Codex Skills are reusable workflows that package instructions, resources, and optional scripts so Codex can follow a workflow reliably. They use progressive disclosure: Codex initially sees lightweight metadata and loads full instructions only when a skill is relevant.

That is the right pattern.

Do not give the agent a thousand-page handbook.

Give it a routing layer.

Examples:

• Migration skill
• Release skill
• Debugging skill
• Test-generation skill
• Security-review skill
• Design-system skill
• Data-backfill skill
• Service-onboarding skill

Each skill should contain the minimum context, commands, examples, scripts, and acceptance criteria needed to do the work correctly.

This turns engineering practice into reusable agent infrastructure.

A senior engineer's judgment becomes a playbook.

A repeated review comment becomes a lint rule.

A debugging habit becomes a command.

A migration checklist becomes a skill.

A production incident lesson becomes a test.

That is how human taste compounds.

The strategic implication

Agentic coding will not reward messy engineering organizations.

It will expose them.

Weak tests, flaky CI, scattered documentation, unclear ownership, hidden architecture, inconsistent logging, and tribal knowledge already slow teams down. Agents make these problems sharper because agents cannot rely on hallway conversations or organizational intuition.

What the agent cannot see, it cannot use.

What the agent cannot run, it cannot verify.

What the agent cannot understand, it will approximate.

What the system does not enforce, the agent will eventually violate.

The best teams will not simply buy coding agents.

They will refactor their engineering systems for coding agents.

They will make repositories legible.

They will make tests fast and meaningful.

They will make logs queryable.

They will encode architectural boundaries.

They will turn documentation into a system of record.

They will use MCP and agent skills to connect agents to the right tools without flooding context.

They will treat permissions and sandboxing as first-class infrastructure.

They will build evaluation loops around real work, not demos.

They will stop asking:

Can the model write code?

They will ask:

Can our system turn intent into verified change?

Conclusion: the agent is the new build target

The next wave of software productivity will not come from sprinkling LLM calls into existing workflows.

It will come from redesigning the engineering environment so agents can do real work.

That means the agent becomes a first-class build target.

You design APIs for agents.

You design docs for agents.

You design logs for agents.

You design tests for agents.

You design permissions for agents.

You design review loops for agents.

The model is not enough.

The agent is not enough either.

The durable advantage is the harness around the agent: the tools, context, constraints, feedback loops, and organizational memory that let agents act safely and improve over time.

The winning teams will not be the ones with the most prompts.

They will be the ones with the best agent operating environment.

Build around the agent.

That is where the leverage is.

References

• OpenAI, "Harness engineering." OpenAI
• OpenAI Developers, "Codex Cloud." OpenAI Developers
• OpenAI Developers, "Codex agent approvals and security." OpenAI Developers
• OpenAI Developers, "Codex Skills." OpenAI Developers
• Anthropic, "Claude Code." Anthropic
• Anthropic, "Claude Code: Security." Claude Code Docs
• Anthropic Research, "Claude Code expertise." Anthropic
• Anthropic Engineering, "Writing tools for agents." Anthropic
• Anthropic Engineering, "Code execution with MCP." Anthropic
• Model Context Protocol, "Introduction." Model Context Protocol
• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models. arXiv
• Schick et al., Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv
• Jimenez et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues? arXiv
• SWE-bench, "SWE-bench Original." SWE-bench
• Yang et al., SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. arXiv