A short introduction for engineering leaders who are new to agentic AI. It explains what a language model actually does, what fills its context, why that limits what agents can do, where tools stand today, and which engineering disciplines move you from steering prompts to running a software factory.
1. It’s autocomplete, just a very good one
A language model does one thing: it continues the conversation. You give it everything said and read so far, and it writes the most likely continuation.
That everything-so-far is called the context. The model works only from the context. It has no memory between replies. Each time, it rereads the whole context from the top and writes the next part.
That is why a new chat starts from zero: the earlier messages are no longer in the context. When an agent seems to “remember” something from last week, it saved a note earlier and loaded that note back into the context.
An agent is a language model plus a harness. The model only writes text, but that text can be a request: read this file, search for this, call this API. The harness — the program around the model — carries out the request and adds the result back into the context. The model then continues from there.
2. The context holds more than you think
When you use an agent, you see your messages and its answers. That is only part of what it reads. The context also holds:
Your messages and its answers.
Instructions the agent received before you typed a word.
Descriptions of the tools it can use.
Every file, web page, and API response it has opened — including the ones it did not need.
Its own intermediate steps and tool results.
It grows with every step and never shrinks unless something cuts it.
Everything the agent reads or opens stays in the context. As it fills, each reply costs more and answers tend to get worse, often well before the advertised maximum.
A fuller context means higher cost and slower replies. Every reply re-reads the whole thing. Irrelevant content can bury the detail that matters. Relevant content can help.
Vendors advertise very large windows. There is no fixed best size. Tests show answers often get worse well before the advertised limit. How early depends on the model and the task (RULER, Hsieh et al., 2024, as of October 2026; Lost in the Middle, Liu et al., 2024, as of October 2026). Include what the task needs. Leave out the rest.
When the window fills up, the agent summarizes or drops older parts to make room. Summaries lose detail, and the detail you needed may be one of the parts that is gone.
3. Practical implications
If the context decides the quality of the answer, the practical goal is simple: give each agent the right information, not as much information as possible.
One agent, one job. A focused agent needs less information, so its context stays small and relevant. An agent asked to do everything has to carry everything.
Organize information so agents can find the right part fast. Clear structure, clear names, and the relevant section rather than the whole file. When documents are easy to navigate, the agent reads what it needs and leaves the rest out of its context.
Every output becomes another agent’s input. Low-quality output adds noise to every context that follows. Clear, precise output keeps the next context clean. Long or vague output pollutes every step after it.
4. Where AI tools stand today: four steps
It helps to place any product on four steps. With each step up, people make fewer decisions, but bigger ones: on the first step you decide at every turn; higher up you decide how the work is set up, what the goals are, and what gets approved.
prompt engineering — step 1 → 2
context engineering — step 2 → 3
harness engineering — step 3 → 4
Each riser is a discipline: prompt engineering lifts you to one-shot agents, context engineering to loops that check themselves, harness engineering to factories.
Step 1 — prompt AI. You work with an agent interactively. You ask, read the answer, correct it, and ask again, steering every turn. Often called vibe coding.
Step 2 — run agents. The work is prepared in advance. Reusable instructions — skills, workflows, or custom agent definitions — describe the task and the tools. The agent then completes the task in one go, without anyone steering it. Example: a custom review agent that runs the team’s checks in one pass.
Step 3 — run agentic loops. An agent repeats a task until it passes a check, such as tests or a code review. This is not a fixed script: the agent judges the result each time and decides what to fix. Example: review and fix a pull request until it can be merged.
Step 4 — the software factory. Specialised agents break a goal into tasks, prepare them, and implement them in parallel. Defined verification and integration steps let this run for hours or days. Real examples exist: Factory’s Missions split work into parallel tracks (Factory Missions overview, as of October 2026), and Vercel runs a factory for its AI SDK in which nothing is merged without a human maintainer’s approval (Vercel: building a software factory for AI SDK, as of October 2026). Both are still early, and the factory is the subject of the rest of this report. For background on reliable coding-agent patterns, see also the research monograph on engineering reliable coding agents (arxiv.org/abs/2608.13867, as of October 2026).
5. Three disciplines that lift you up
Moving up the steps is not about a bigger model. It is about three engineering disciplines. Each one unlocks the next step.
Step 1 → 2
Prompt engineering: make the task repeatable
What it is: writing reusable instructions — skills, workflows, and custom agent definitions — that describe the task, the constraints, and the tools, so the knowledge does not live only in chat history.
What it enables: an agent that completes a task in one go, without steering. You stop prompting turn by turn and start reusing a defined task.
Example: a review skill that tells the agent which files to read, which checks to run, and what a good review looks like. The team runs the same review agent on every change instead of re-explaining the process each time.
When it is missing: every task needs hand-holding. Results vary with who prompts and how they phrase it, and work stops when you stop typing.
Step 2 → 3
Context engineering: decide what the agent sees each time
What it is: deciding what goes into the agent’s context on every iteration — the task, the relevant files, the check results, short notes, and summaries — so the loop has what it needs and nothing more.
What it enables: an agent that can loop until a check passes without drowning. The agent sees each failure, fixes it, and tries again.
Example: a fix loop that feeds back only the failing test output plus the relevant files, keeps a short note of what was already tried, and summarizes older turns before the context fills up.
When it is missing: the loop drowns. Unneeded files pile up, cost and latency grow, the check output gets buried, and after a summarization the detail the fix depended on is gone.
The loop is simple: act, check, put the result back into the context, repeat. The check — not a fixed script — decides when to stop.
Step 3 → 4
Harness engineering: build the system around the agents
What it is: building the system around the agents — task breakdown, specialised agents, parallel runs, isolated workspaces, verification and integration gates, a retained store of requirements and decisions, and human approvals.
What it enables: work that runs for hours or days without constant supervision: the software factory. Parallel tracks move at once, gates catch bad changes, and people approve what matters.
Example: a goal is broken into small tasks; specialised agents implement them in parallel in isolated workspaces; verification gates run tests and reviews; passing work integrates; a human approves the merge. Requirements and decisions stay in a shared store so the next agent can pick up where the last one left off.
When it is missing: parallel work collides, unverified changes slip through, nobody knows what was decided or why, and a long run cannot be trusted or resumed.
A factory is a harness: one goal, many isolated agents, gates before integration, and a human decision at the end — all reading from the same retained requirements and decisions.
6. What ages fast, and what lasts
Most skills and workflows are now written by agents. AI is already building the next software factories.
They age in months, not years. A skill that is an advantage today can be built into the platform tomorrow, or need re-checking when the next model arrives. Community review skills were widely copied when they were the only way to get a good review; similar review support now ships with leading tools. Reuse skills that cut duplicated code have to prove themselves again with each model generation.
A factory made only of skills and workflows ages the same way. The parts get replaced.
Two things last:
Well-structured knowledge — requirements, specifications, and decisions with the reasons behind them — that the next agents can reuse. If it is well structured, any new model or workflow can pick it up and continue. If it is buried in chat logs or long reports, it has to be rebuilt each time.
Judgment about how the factory runs: knowing what goes into the context, how the work is checked, and where people decide. Together that judgment builds a factory, and rebuilds it when the parts change.
Next: what a software factory has to do
This primer covered how agents work and what lifts them from prompts to factories. The next step is what a factory must actually do to be trusted in an enterprise.
Sources cited above were checked as of October 2026. Model capabilities, built-in features, and popularity change fast; where no source is given, claims are stated without numbers on purpose.
