# Agentic Engineering: What Agents Need Besides the Model


URL: https://getunblocked.com/blog/agentic-engineering-what-agents-need/
Published: 2026-11-05T14:25:00Z
Author: Dennis Pilarinos
Categories: Context Engine, Engineering Insights

Agentic engineering runs on five layers: model, harness, permissions, evals and context. Over 40% of GitHub PRs began as agent drafts by Sept 2026.

---
Agentic engineering needs five layers to work in a large codebase, and the model is only one of them. The other four are the harness that runs the agent, the permissions it acts under, and the evaluation that checks its work. The last is context: why the code looks the way it does. Teams tend to buy the model, build the harness, bolt on permissions and evals, and leave the fifth layer to whatever the agent can find in the checkout. That gap now shows up at scale. By September 2026, more than 40% of pull requests on GitHub started with an agent's first draft, up from 17% in March, about 110 million in that month alone ([GitHub Octoverse 2026](https://github.blog/news-insights/octoverse/octoverse-commits-pushes-reach-new-highs-in-2026-as-developers-build-with-agents/)). **Agentic engineering** is the practice of building software with coding agents that plan, write, test and open changes, with engineers setting the goals and owning the result. This page lays out each layer, what it owns, and where it stops.

## Agentic engineering: what do agents need besides the model to work in a large codebase?

Four things, each with a different owner. Simon Willison's 2026 guide to agentic engineering puts the core mechanism in one line: "Agents run tools in a loop to achieve a goal" ([Agentic Engineering Patterns](https://simonwillison.net/guides/agentic-engineering-patterns/what-is-agentic-engineering/)). Everything outside the model exists to make that loop safe, useful and correct.

- **The harness** runs the loop. Anthropic defines it as "the system that enables a model to act as an agent" ([Anthropic, January 2026](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)): tools, sandbox, retries, review gates.
- **Permissions and identity** decide what the agent may touch and whose authority it acts under.
- **Evaluation** tells you whether the output is right before a customer does.
- **Context** supplies what the code cannot say about itself: the decision behind a design, the owner of a service, the incident that shaped a retry policy, the pull request that already did this work.

The first three are well tooled in 2026. Most teams find the fourth late, after a week of plausible pull requests that miss the point.

## Why doesn't a stronger model close the gap on its own?

Because the hard part in a large codebase is finding the right material, and better scaffolding has not solved that. ContextBench, a February 2026 benchmark of 1,136 issue-resolution tasks across 66 repositories, found that "sophisticated agent scaffolding yields only marginal gains in context retrieval" and that models "consistently favor recall over precision" ([arXiv 2602.05892](https://arxiv.org/abs/2602.05892)). Agents read a lot and use little of it.

ReCUBE, a March 2026 benchmark that asks models to rebuild a file from the rest of its repository, reports the best result as a 37.57% strict pass rate for GPT-5 in the full-context setting ([arXiv 2603.25770](https://arxiv.org/abs/2603.25770)). And writing more instructions into the repo is not a reliable fix. A 2026 study of AGENTS.md files found they generally did not improve task success and raised inference cost by over 20% on average ([arXiv 2602.11988](https://arxiv.org/abs/2602.11988)).

The inputs decide the output, and the inputs that matter most often live outside the repository.

## The five layers of an agentic engineering stack

Each layer fails in its own recognizable way. The table is the short version, and the sections after it take the layers one at a time.

| Layer | What it owns | What breaks without it | Example tools |
| --- | --- | --- | --- |
| Model | Reasoning, code generation, tool-call decisions. | Nothing runs; weaker models stall on multi-step work. | Claude, GPT, Gemini model families. |
| Harness | The loop, tools, sandbox, retries, review gates, handoffs. | The agent cannot act, or acts with no checkpoints. | Claude Code, Codex, Cursor, internal agent platforms. |
| Permissions and identity | What the agent may read, run and change, and on whose behalf. | Overreach, leaked data, actions nobody can attribute. | Claude Code permission rules and sandbox, branch rulesets, SSO. |
| Evaluation | Whether the output is correct and whether a change made the agent better or worse. | Regressions ship; quality is judged by vibes and incidents. | Eval suites with graders, separate evaluator agents, CI tests. |
| Context | Why the code is this way, who owns it, what was tried, decided or broken before. | Plausible PRs that duplicate work, repeat rejected designs or reopen old incidents. | A context engine such as Unblocked; rules files for conventions. |


## What does the harness own, and where does it stop?

The harness owns everything about running the agent: the loop, the tool calls, the sandbox, the checkpoints and the handoff between sessions. Anthropic's March 2026 write-up on long-running work describes splitting a "generator" agent from an "evaluator" agent, because "agents reliably skew positive when grading their own work" ([Anthropic engineering](https://www.anthropic.com/engineering/harness-design-long-running-apps)). The same post describes context resets that pass state to a fresh agent through a structured handoff.

Isolation is a harness job too. Claude Code's sandbox gives a sandboxed command "no direct route to the network" and by default limits writes to the working directory plus a few added paths ([Claude Code docs](https://code.claude.com/docs/en/sandboxing)). GitHub's coding agent works on one branch at a time, opens one pull request per task, and can be blocked by a ruleset or branch protection rule ([GitHub Docs](https://docs.github.com/en/copilot/concepts/agents/coding-agent/about-coding-agent)).

The harness stops at the edge of what the agent knows. A handoff carries the last session's state. It cannot carry a Slack decision from 2023 that the agent never saw.

## How should permissions and identity work for agents?

Every action should trace to a person or a service identity, and every read should respect the reader's access in the source system. Claude Code's permission rules "are evaluated before any tool runs," and the operating system enforces the sandbox boundary "regardless of what the model chose to run" ([Claude Code docs](https://code.claude.com/docs/en/sandboxing)). That covers what the agent can do on the machine.

Identity is the harder half. The Model Context Protocol maintainers wrote in August 2026 that "MCP authorization today is built around a person approving access in a browser." The new callers are agents "acting on behalf of a user who isn't present" ([MCP blog](https://blog.modelcontextprotocol.io/posts/mcp-roadmap/)). An unattended agent needs credentials that belong to it, scoped to the task.

Shared context raises the stakes. An April 2026 study of agents with shared state found benign use alone produced cross-user contamination rates of 57% to 71% ([arXiv 2604.01350](https://arxiv.org/abs/2604.01350)). A context layer that many agents read from has to answer each request as the person or service asking, with source permissions applied first.

## How do you know the agent did the job well?

You test it the way you test any system: fixed tasks, clear pass criteria, and a grader that is not the agent itself. Anthropic's January 2026 guide describes an eval as an input plus "grading logic to its output to measure success" for an AI system. It also warns that "teams without evals get bogged down in reactive loops" ([Anthropic engineering](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)).

GitHub's Octoverse is careful on this point: its figures "describe observed use, not model quality." The same report found that use of AI-assisted code review grew more than 90% year over year ([GitHub Octoverse 2026](https://github.blog/news-insights/octoverse/octoverse-commits-pushes-reach-new-highs-in-2026-as-developers-build-with-agents/)), which tells you where teams feel the risk.

Evals catch a wrong answer after the fact. They rarely explain why the agent was wrong. When the failure is "it rebuilt something we already had" or "it ignored the reason this client retries three times," the eval exposes the symptom, and the fix sits in the context layer.

## What context lives outside the code?

Most of what a senior engineer knows about a system. In the 2026 Stack Overflow Developer Survey, 63% of developers named incomplete information as a barrier to getting context, and 79% regularly find what they needed only after the fact ([Stack Overflow, 2026](https://survey.stackoverflow.co/2026/)). Close behind, at 61%, was important context that lives in people's heads.

The same survey asked what AI agents most need to have. Project goals or requirements came first at 85%, then code and docs at 73%, prior decisions at 44% and related tickets at 37% ([survey results](https://survey.stackoverflow.co/2026/)). Prior decisions and tickets are not in the repository. They sit in pull request threads, Jira, Slack, design docs and incident reviews, and they often disagree.

A **context engine** is a system that connects code, pull requests, tickets, docs, chat and incidents, resolves conflicts between them, and returns a cited, permission-filtered answer to the person or agent asking. That is the fifth layer. The longer explanation is in [what is a context engine](https://getunblocked.com/blog/what-is-a-context-engine/), and the most common question it answers is the one in [why was this built this way](https://getunblocked.com/blog/why-was-this-built-this-way/).

## Do agentic applications need a context engine?

Past a certain size, yes. In a small repo owned by one team, the code and a short rules file carry most of what matters, and the developer at the keyboard supplies the rest. In a large codebase with years of history, many teams and agents running unattended, nobody is at the keyboard to supply it.

The architecture split is simple. The agent, CI runner or backend service owns the workflow and the actions: it plans, edits, runs tests, opens the PR. The context layer owns why, who and what happened before. It does the research across sources, settles which source is current, and hands back a short cited answer. Keeping that split clean means each agent you add reuses the same context instead of rebuilding it with its own pile of MCP connectors.

**Decision-grade context** is context that has been gathered across sources, reconciled where they disagree, and filtered to what the asker may see, so an agent can act on it. With retrieval alone, the agent gets a stack of documents to reconcile itself, and that is where tokens and mistakes go. [Code isn't context, and MCP isn't enough](https://getunblocked.com/blog/code-isnt-context-mcp-isnt-enough/) covers that difference in depth.

## What does the split look like in real workflows?

In October 2026 we analyzed the automated workflows 141 customer organizations had built on Unblocked and grouped them by job; the per-family counts are in [how enterprise AI agents get company context](https://getunblocked.com/blog/enterprise-ai-agents-company-context/). Six families came out, and in every one the agent owns the actions while the context layer supplies the history.

1. **Ticket to plan to PR.** The agent reads the ticket and writes the code. The context layer brings in the earlier attempt, the design thread and the owner.
2. **Contextual review and risk.** The reviewer bot comments on the diff. The context layer explains which past incident this file was involved in.
3. **Incident investigation.** The agent reads logs and proposes a fix. The context layer finds the change and the conversation that explain the error.
4. **Support enrichment.** A support agent drafts the reply. The context layer adds how the feature actually behaves; see [context for support and ops agents](https://getunblocked.com/blog/context-for-support-and-ops-agents/).
5. **Scripted research.** A CI job or script asks a question and stores a cited answer as a record.
6. **Test generation.** The agent writes tests. The context layer supplies the edge cases past bugs revealed.

## What happened when Webflow's agents got the missing layer?

Webflow runs agents on Flower, its internal remote-agent platform, and connected Unblocked over MCP inside Flower's sandbox, next to its other MCP servers ([Webflow customer story](https://getunblocked.com/customers/webflow/)). Webflow had already rolled out Claude, Cursor and Codex. The models and the harness were in place. What changed was that agents could ask why, who and what happened before, and get institutional context for coding agents back over the same MCP connection. Russ Nealis, Staff Technical Product Manager, described the moment it paid for itself:

> An engineer asked an agent to implement a feature, and Unblocked discovered it had already been implemented elsewhere in the codebase. That would've been an enormous waste of time to re-implement. Unblocked said, 'Hey, check out this PR that does exactly what you're trying to do,' and we short-circuited all of it.
>
> — Russ Nealis, Staff Technical Product Manager, Webflow


A build-and-test eval would likely have passed that run. Only the context layer knew the work already existed. The same pattern, an agent rediscovering what the team already knows, is the subject of [how to stop a coding agent repeating discovery before every task](https://getunblocked.com/answers/stop-coding-agent-repeat-discovery-before-every-task/).

## Where to start: audit your five layers

The bottom line for a platform team is an audit. Write the five layers down and put a name next to each. Most platform teams can fill in the model, the harness and permissions in a minute. Evaluation usually has a partial answer, such as CI tests plus a few hand-checked runs. Context is often blank, or it says "AGENTS.md," which the 2026 research suggests is the wrong tool for that job.

Then pick one workflow from the six above (ticket to PR is the usual first choice) and trace a failed run back to its cause. If the cause was a missing decision, owner or prior attempt, the fifth layer is your next build or buy. [Context for background coding agents](https://getunblocked.com/blog/context-for-background-cloud-agents/) covers what an unattended run needs before it starts, and [the 8 levels of agentic engineering](https://getunblocked.com/blog/8-levels-of-agentic-engineering/) shows where each layer starts to matter as a team matures. [Unblocked](https://getunblocked.com/about/) is the context engine for engineering, and it plugs into Claude Code, Cursor, Codex and other MCP clients as that layer.

## FAQ

### Is agentic engineering the same as vibe coding?

No. Vibe coding usually means accepting generated code you have not read, which suits prototypes. Agentic engineering keeps the professional quality bar: engineers set goals, review the output and stay accountable, while agents do much of the typing and testing.

### Can a bigger context window replace the context layer?

Not on its own. ReCUBE's best model reached a 37.57% strict pass rate even with the full repository in context ([arXiv 2603.25770](https://arxiv.org/abs/2603.25770)). A larger window also does nothing for decisions that were never written into the code.

### Do I still need AGENTS.md or CLAUDE.md files?

Yes, for short, non-standard conventions. The 2026 AGENTS.md study found the files are followed well but repository overviews in them did not help ([arXiv 2602.11988](https://arxiv.org/abs/2602.11988)). Keep them brief and leave history to the context layer.

### Who should own the context layer?

The platform or developer-experience team, the same group that owns the harness. Every agent, CI job and bot then calls one shared layer, which keeps answers consistent and permissions in one place.