Agentic Engineering: Building the System Around the Model

A few years ago, I wrote about building future-proof software. The conclusion was not that we had found a way to predict the future of software. Technology, businesses, and user expectations change too quickly for that. The best we can do is build software, teams, and processes that are ready to adapt when the next change arrives.

Today, the same thought keeps returning while I work with AI agents.
The models are improving at an extraordinary rate. A task that recently required a carefully constructed prompt may now work on the first attempt. Every release makes it tempting to believe that the remaining problems will disappear with the next increase in intelligence.

But imagine hiring an exceptionally capable engineer and giving them no onboarding, no company standards, no issue tracker, no access to the application, no way to run tests or see logs, and no clear authority. Then ask them to deliver a production-ready feature.

This would obviously fail, but not because of a lack of intelligence. The right environment does not exist. The same, if not more, applies to AI. A capable model is necessary, but the model is only one part of an agentic engineering system. Around it, we must engineer instructions, context, ways of working, tools, execution, feedback, coordination, and governance.

Prompt engineering: shaping the instruction

Prompt engineering is the most familiar layer. It is the work of expressing an objective, constraints, examples, and expected output in a form that helps a model respond well. For a bounded task, that may be everything we need. We can ask a model to explain a function, draft a user story, generate unit tests, or review a code fragment. A precise prompt reduces ambiguity:

Review this endpoint for authorization problems. List only actionable findings, cite the affected lines, and explain the possible impact.

This is more useful than asking, Is this code secure? We have defined the review, the output, and the evidence we expect.

But a prompt cannot contain the entire world around the task. Which authorization standard do we follow? What business roles exist in the product? Is authentication handled upstream? Which risks have already been accepted? What tools can inspect the rest of the repository?

We can keep expanding the prompt until it becomes an instruction manual, but then relevant information competes with irrelevant information and quickly becomes stale. A good prompt explains the task. It does not replace the system around it.

Context engineering: shaping what the model can see

The prompt is only one part of what a model receives. Its context may also contain system instructions, conversation history, tool descriptions, retrieved standards, source code, plans, earlier results, and observations from the environment.

Anthropic describes context engineering as curating the optimal information for a model at each inference step. The goal is not to provide the maximum amount of information. It is to provide the smallest set that is sufficient, relevant, and trustworthy.

This is crucial in software engineering. A repository may contain millions of lines of code, years of decisions, hundreds of standards, and an issue history that no context window should absorb at once. An effective agent needs a map and a way to retrieve detail when it becomes relevant.

At IBORN, our standards can provide part of that map. They capture practices across development, QA, security, design, DevOps, data, and other areas. They are versioned, reviewed, and already used to evaluate projects.

We should not copy all of them into one enormous system prompt. A specification agent should retrieve guidance about business goals and acceptance criteria. A code-review agent should retrieve relevant development and security standards. A QA agent should prioritize testing and release-readiness standards. An evaluation agent should cite the exact standard behind every assessment.

This is just-in-time context: begin with a small map, then load the information required by the current decision. Context must also be maintained as the agent works. New observations enter, old details lose relevance, and important decisions move into durable storage before the context disappears.

Skills: packaging repeatable ways of working

Some instructions do not belong to one task, but they also do not belong permanently in every model interaction. They describe a repeatable way of working. This is the role of a skill.

A skill packages a procedure for a recognizable goal. It can define when the workflow applies, which sources to consult, which tools to use and in what order, what evidence to collect, what the output must contain, and when the agent should stop or escalate. It may also include focused references, templates, or scripts.

OpenAI describes skills as reusable workflow instructions and resources that complement tools. A tool provides live information or a controlled action; a skill teaches the model how to combine those capabilities into a repeatable workflow. The agent can initially see only a skill's name and description, then load its full instructions when the task matches.

This gives us a useful separation:

• A prompt describes the current task.
• A standard describes what the organization knows, requires, or considers good practice.
• A skill describes how an agent should perform a particular kind of work.

An IBORN QA skill, for example, can instruct an agent to begin with our Quality standards, also examine relevant Development, Security, and DevOps standards, cite what it applies, produce a structured test strategy, and hand compliance scoring to the evaluation workflow. It should not copy all QA standards into the skill. Those standards evolve independently and remain the source of truth.

Skills should stay thin and focused. They are also not enforcement. A skill may tell an agent never to deploy directly to production, but the harness should make that impossible or require approval. If a boundary matters, encode it in the environment rather than trusting the model to remember it.

Harness engineering: shaping the environment

Even the best-informed model cannot inspect a repository, run a test, update an issue, or create a pull request unless we give it a way to act.

The harness is the software system surrounding the model. It translates model output into controlled action and returns observations to the model. It may provide repository, shell, browser, and issue-tracker tools; sandboxed execution; authentication and permissions; persistence; context management; traces and limits; validation; recovery; and human approval gates.

OpenAI calls the harness the layer that turns model capability into real-world action. Its account of harness engineering with Codex also makes a point I find especially useful: when an agent repeatedly fails, “try harder” is rarely the durable answer. We should ask which capability, constraint, feedback mechanism, or piece of legible information is missing from its environment.

The harness should expose meaningful capabilities without leaking infrastructure details. An external agent should be able to search our standards without knowing where they are stored. It should be able to create an evaluation draft without understanding our database schema.

MCP gives us a useful boundary here. A standards service can expose search and retrieval. A repository service can expose inspection and review. An issue service can expose provider-independent coordination. The implementation behind each tool can change without rewriting every agent that uses it.

This is also where safety becomes concrete. Be careful is a prompt. A sandbox, a read-only credential, and an approval requirement are enforceable boundaries.

Loop engineering: shaping progress and feedback

A model call produces a response. An agent loop produces progress. The basic loop is simple: understand the current state, choose an action, use a tool, observe the result, and then continue, correct, finish, or escalate. OpenAI's description of the Codex agent loop presents this as the core logic connecting the user, model, and tools.

Consider a failing test. A coding assistant may propose a patch. An agent can find the failure, inspect the related code, make a change, run the test, observe a new failure, inspect the logs, correct the implementation, rerun the suite, and summarize the result.

The loop sounds simple, but its design determines whether an agent is persistent or merely expensive. We need completion criteria, time and cost budgets, checkpoints, sensible retries, and escalation when progress stops. Most importantly, we need validation of the result rather than trusting the agent's claim that it succeeded.

Feedback quality is decisive. A clear test failure, an actionable lint message, or an observable application state gives the agent something concrete to correct. The best loops convert our expectations into signals the agent can observe.

Agent orchestration: shaping coordination

One loop is enough for many tasks. Building a product, however, rarely follows one uninterrupted path.

A specification may require approval before implementation. Development and test preparation may run in parallel. A security finding may send work back to development. Deployment may wait for several independent checks. Some decisions belong to deterministic software, some to agents, and some to people.

This is the scope of agent orchestration: designing how those parts work together. A graph is one useful representation, especially when the workflow contains shared state, conditional branches, parallel work, cycles, and approval gates. A node may be an agent, a function, a test suite, a human decision, or an external event. An edge determines what may happen next. Frameworks such as LangGraph formalize this model through state, nodes, and edges, as described in LangGraph's official Graph API overview.

But the graph is a representation, not the whole discipline. Orchestration also covers task decomposition, routing, handoffs, scheduling, persistence, recovery, and deciding when coordination should be dynamic instead of encoded in a fixed graph. This is why I prefer agent orchestration to the emerging term graph engineering, which can also be mistaken for knowledge-graph engineering or GraphRAG.

In the system we are exploring at IBORN, an orchestrator decomposes a goal and assigns work to specialist agents. The issue tracker becomes their durable coordination ledger. It records ownership, dependencies, status, evidence, and approvals, not merely the messages exchanged during one run.

Conversation is where agents reason. Orchestration is how work flows. The issue tracker is where the organization remembers.

Agentic engineering: shaping the complete system

We now have the technical layers, but dependable software delivery is not only a technical problem. Agentic engineering puts these layers inside an operating model. It decides which outcomes matter, which knowledge is authoritative, which workflows become skills, who owns each responsibility, which tools and data are accessible, what evidence is required, and which decisions remain human.

This makes agentic engineering more than another name for harness engineering or orchestration. It includes the organization around the runtime: standards, workflow ownership, permissions, auditability, evaluation, and accountability across the software lifecycle.

The word engineering is doing most of the work. Models can generate. Engineering makes the result consistent, repeatable, testable, maintainable, and appropriate for its consequences.

Agentic Engineering vs. Prompt Engineering

Prompt engineering optimizes an instruction for one model interaction. Agentic engineering designs the wider system that carries a goal through context, reusable methods, tools, feedback, coordination, and governance.

Prompt engineering remains part of that system; it is not replaced by it. Use a prompt for a bounded response. Engineer the wider system when work spans multiple steps, tools, state changes, specialists, or consequential decisions.

One goal through all seven layers

Imagine that a team needs to introduce a new authorization capability into an existing product.

The prompt defines the goal, constraints, and expected result. The context contains the product specification, current authorization architecture, relevant source code, earlier decisions, and applicable IBORN standards. The skill defines how we approach this kind of change: what to inspect, which tools to use, what evidence to collect, and when to escalate.

The harness gives the agent controlled tools to inspect the repository, edit an isolated branch, run tests, search standards, and update issues. It cannot merge or deploy. Inside the loop, the development agent implements, tests, observes failures, corrects its work, and stops when the checks pass or a blocker requires escalation.

Through orchestration, specification, implementation, security review, QA, and evaluation become connected work. Some tasks run in parallel, failed checks return work to the right step, and consequential transitions wait for human approval.

At the agentic engineering level, the organization decides which standards apply, what evidence is sufficient, where state is recorded, who owns the workflow, how success is measured, and where human authority begins.

No single layer is enough. A good prompt without context produces a well-structured guess. Context without a reusable method forces every task to reinvent the work. A skill without a harness describes actions the agent may not be able to perform safely. A harness without a good loop produces tool use without dependable progress. A loop without orchestration struggles with cross-functional work. Orchestration without governance can coordinate the wrong actions very efficiently.

Start at the failure, not the buzzword

This model gives us a practical way to improve agent systems: identify the layer where the failure lives.

If the agent misunderstands the task, improve the prompt. If it lacks a relevant standard or decision, improve context discovery. If it finds the right information but follows an inconsistent method, improve the skill. If it cannot inspect or validate the result, improve the harness. If it repeats itself or stops too early, improve the loop. If dependencies and handoffs break down, improve orchestration. If the result is technically successful but unsafe or disconnected from business value, improve the agentic engineering system.

We should measure the same way. Task completion alone is not enough. Human correction rate, standards coverage, defects caught before release, cycle time, escalation frequency, and cost per accepted outcome tell a more honest story. A faster agent that creates more review work is not necessarily an improvement.

Final Thoughts: Engineering Remains Human-Directed

Agentic engineering does not remove people from engineering. It changes where people focus their attention.

As code generation becomes less scarce, the bottleneck moves toward intent, product judgment, design, architecture, standards, validation, empathy, and business goals. These responsibilities are not new. We have simply neglected some of them under the pressure to deliver more code in less time.

People remain accountable for the result. Agents can take on more of the searching, coordinating, checking, documenting, and repetitive execution around our decisions. They can bring relevant knowledge into the workflow earlier and make feedback available sooner. Their autonomy can expand where repeated evidence shows that it is safe and valuable.

We cannot predict which model, framework, or agent platform will dominate the next few years. We can build an engineering organization whose knowledge is structured, whose methods are reusable, whose tools have clear interfaces, whose loops receive meaningful feedback, whose workflows are visible, and whose authority is deliberately assigned. That may be the most future-proof system we can build.