AI Agent Engineering:
Principles, Orchestration, Safety, and ROI

Before discussing implementation details, it helps to break an Agent system into four layers: goal, instruction, context, and model.

• Goal layer: defines what the Agent should ultimately deliver. Vague goals tend to produce over-execution, scope drift, or shortcuts. A good goal includes the output format, information sources, boundaries, and completion criteria.
• Instruction layer: defines how the task should be done and which actions are not allowed. This includes system rules, task constraints, tool limits, and reusable instruction modules.
• Context layer: contains everything the Agent can see while making decisions: conversation history, file contents, retrieval results, tool outputs, and memory. Context quality directly affects output quality.
• Model layer: provides the underlying reasoning and generation capability. Application builders usually do not modify this layer directly, but they need to understand its probability behaviour, context limits, and tool-calling constraints.

The goal, instruction, and context layers together form the harness: the working environment around the model. Agent engineering is not only model selection. It is the design of a system that manages goals, data, tools, evaluation, and permissions.

The Agent loop

When an Agent receives a task, it usually repeats four steps until the goal is reached or it hits an explicit blocker:

1. Find the goal: extract the objective from the prompt and surrounding context. If the objective is vague, the model will infer one, and the inferred goal may not match the user's intent.
2. Gather context: read the available information sources, such as the current conversation, files, memory, instruction modules, and tool outputs.
3. Plan steps: decide what to do first, which tools to call, and how each step should be verified.
4. Execute and observe: call tools, inspect results, update the plan, and continue the loop.

It is tempting to imagine an LLM as a large knowledge database. That intuition is incomplete. An LLM is more accurately described as a next token predictor: given input text, it estimates a probability distribution over the next token and generates from that distribution.

What is a token

A token is the basic unit of text that a model counts and processes. A tokenizer might split generates the most likely next token, word, or phrase into units such as generates, the, most, likely, next, token, ,, word, or, and phrase.

The exact split depends on the tokenizer. Different tokenizers can produce different token counts for the same text, which affects context capacity, latency, and cost.

Why output varies

Suppose the input is generates the most likely next. The model may estimate that several continuations are plausible:

• token: 50%
• word: 30%
• phrase: 20%

The model does not always choose the highest-probability token. It samples according to the distribution and decoding settings, so repeated runs can produce different answers. This is the source of LLM non-determinism.

Temperature and reasoning controls

Temperature changes the sampling distribution. Higher temperature makes output more diverse and exploratory; lower temperature makes output more stable and repeatable. Creative drafting, brainstorming, and exploration can benefit from higher variance. Compliance checks, classification, structured extraction, and evaluation usually benefit from lower variance.

Some model runtimes also expose reasoning-depth controls. These are not identical to temperature, but they can affect how much computation the model spends on planning, checking, and revising before it returns the final answer.

Once you treat the model as a probability machine rather than a lookup system, common behaviours such as hallucination, sycophancy, over-execution, and unstable output become easier to explain and manage.

Large models differ in capability, style, and behaviour because their data mix, optimisation process, and alignment methods differ. A typical development process includes these stages:

1. Pre-training: the model learns statistical patterns from large-scale text, code, and multimodal data. This gives it broad language fluency and general knowledge, but not necessarily reliable task-following behaviour.
2. Supervised fine-tuning: curated examples teach the model how to follow instructions, produce useful formats, and handle specific domains or task types.
3. Human feedback optimisation: evaluators review answer pairs and produce preference signals. This improves usability and instruction-following, but it can also encourage overconfidence or excessive agreement.
4. AI feedback and distillation: one model can act as an evaluator or teacher for another model. This expands evaluation scale and can transfer behaviour, structure, and style between systems.

These stages improve usefulness, but they also create engineering risks. A model can learn to produce answers that look good to an evaluator even when they are incomplete, unverifiable, or too confident.

The following traits are common engineering risks in LLM systems. They cannot be fully removed, but they can be managed with clear goals, constraints, evaluation, and permission design.

1. Sycophancy: the model may agree too readily or produce what the user seems to want. Ask for critique, counterexamples, uncertainty, and independent review when objectivity matters.
2. Hallucination: the model may invent links, numbers, sources, or conclusions. Require sources, mark unverifiable claims, and verify high-risk outputs independently.
3. Over-execution: broad goals can make the model do too much, scan unrelated material, or expand the task. Limit scope, output length, tools, and stopping conditions.
4. Shortcut-seeking: if the success metric is poorly designed, the model may optimise the visible score instead of the real goal. Define evidence requirements and prohibited actions.
5. Injection susceptibility: the model can treat text from files, pages, prompts, or other model outputs as actionable instructions. Treat external content as untrusted input.
6. Non-determinism: the same input can yield different outputs. Use fixed formats, lower variance settings, tests, and evaluators when repeatability matters.

These traits do not make Agents unusable. They define the failure modes that a reliable harness must manage.

Before building an AI system, it is useful to separate four concepts that are often mixed together:

• LLM: the underlying token prediction model.
• Chatbot: a conversational interface built on an LLM, usually suited to one-off questions, summaries, and explanations.
• Workflow: an automated process with mostly fixed steps and clear inputs and outputs. It is often more stable and cheaper for repeatable tasks.
• Agent: a system that can plan, call tools, read context, and iterate until a goal is complete. It is best suited to open-ended tasks that need multi-step reasoning and tool use.

The design question is simple: are the steps fixed? If yes, a workflow may be the better tool. If the task is open-ended and requires the system to decide what information to seek and which tools to call, an Agent is more appropriate.

Context is central to Agent engineering. What the model can see, what it cannot see, and whether the visible content is trustworthy often matter more than the exact wording of a single prompt.

Context window

Every model has a maximum context window. When an Agent works, context can grow quickly because conversation history, tool results, files, and intermediate outputs may be repackaged into later model calls.

Three costs of large context

• Slower: more tokens increase inference latency.
• Less focused: longer context makes it easier for early constraints or important details to be missed.
• More expensive: input tokens are usually billed, so unmanaged context can multiply cost.

Cost example

As a hypothetical estimate, a fresh interaction may process only a few hundred tokens. A long-running session with 100K tokens of accumulated context may need to resend that history for a tiny new instruction. A 500K-token session can make a trivial message cost many times more than the same message in a fresh session.

Prompt caching

Some model services discount repeated context through prompt caching. If a long prefix remains identical and is reused within the cache window, repeated tokens may be billed at a lower rate. Once the cache expires or the prefix changes, the old context may be billed normally again.

In practice, it is often better to save conclusions and open questions into files, then start a new session from those summaries. This keeps context smaller, clearer, and easier to audit.

Context management toolkit

• Retrieval-augmented generation: index knowledge and retrieve only relevant excerpts when needed.
• File organisation: store background knowledge in structured files instead of pasting everything into the prompt.
• Memory: persist stable preferences, confirmed conclusions, and durable rules across sessions.
• Lean system prompts: keep only essential always-on rules in the system prompt.
• Navigable instruction modules: split large instructions into focused files with clear indexes.
• Summarisation and compression: periodically compress history into decisions, conclusions, open questions, and next actions.

The first principle of context engineering is not to put everything into the prompt. Put information where it can be found, cited, checked, and compressed.

When tasks become complex, a single Agent may not be enough. Common orchestration patterns include:

1. Prompt chaining: split a task into linear steps where each output feeds the next input. This works well when the sequence is clear, but errors can accumulate downstream.
2. Routing: classify the task type and send it to the matching prompt, instruction module, or tool flow. This works well when task categories are known and stable.
3. Parallelisation: assign independent subtasks to separate execution units and merge the results. This works for independent research, comparison, or analysis tasks, but only when the subtasks are truly independent.
4. Orchestrator-worker: one controller plans, assigns, and integrates work while separate workers handle specific pieces. This works for complex projects that need dynamic planning and cross-tool coordination.
5. Evaluator-optimizer: one unit generates an output, a separate unit evaluates it against criteria, and the first unit revises from feedback. This works for content generation, code review, rule writing, and high-quality deliverables.

Using these patterns does not always require writing a custom orchestration engine. It does require clear task shapes, role boundaries, input-output contracts, and evaluation criteria.

Evaluator-optimizer in practice

1. Define the output target: specify the artifact, format, constraints, and acceptance criteria.
2. Generate the first version: produce v1 using the goal, context, and available tools.
3. Evaluate independently: check v1 against the same criteria and list gaps, errors, and risks.
4. Revise from feedback: update only what the evaluation and original goal justify.
5. Repeat until acceptable: continue the loop until the output passes the quality bar or reaches an iteration limit.

The harness is the Agent's management system. It determines how goals are understood, how context is selected, how tools are invoked, how outputs are evaluated, and how permissions are controlled.

• Define goal and scope: write completion criteria and hard boundaries to prevent over-execution.
• Organise context and resources: keep files, memory, instruction modules, and tool outputs findable, citable, and verifiable.
• Manage model traits: design around hallucination, sycophancy, shortcut-seeking, and injection susceptibility.
• Build evaluation and feedback: use rule checks, test sets, independent evaluators, or real data signals instead of trusting self-reports.
• Design permission boundaries: require human review for high-impact operations and follow least privilege for tool access.
• Preserve traceability: log tool calls, input sources, decision summaries, and output versions for audit and rollback.

Do not hand raw credentials to Agents

Agents sometimes need to act on behalf of a user in external systems. The unsafe pattern is pasting browser cookies, session tokens, API keys, or other raw credentials into the model. These credentials are often over-scoped, difficult to audit, and hard to constrain to one task.

Authorization design should answer four questions:

1. Does it require human review? Should high-impact operations require explicit confirmation?
2. Is permission minimal? Does the Agent receive only the scope required for the task?
3. Is access revocable? Can the token or authorization be revoked quickly, and can wrong actions be rolled back?
4. Is activity traceable? Can operators inspect which tools were called, which data was read, and what state changed?

The safer the system is, the more authority an Agent can responsibly receive. Safety is the prerequisite for broader automation.

AI security is not only about what the user types into chat. The real threat surface includes every input source the Agent reads.

Input sources an Agent may read

• User prompts
• Documents, spreadsheets, Markdown, and source code
• Instruction modules and system prompts
• Web search results and page contents
• Copied email, chat, or table content
• Outputs from other models or Agents

What is prompt injection

Prompt injection occurs when malicious instructions are embedded in content the Agent will read, causing it to leak context, override rules, or perform unauthorised actions. A typical attack chain looks like this:

1. External content is introduced: a page, file, prompt fragment, or instruction module enters the task context.
2. A malicious instruction is embedded: the content hides an instruction to ignore rules, exfiltrate data, or call a tool.
3. The model treats it as task context: the Agent reads the content and may follow the embedded instruction during an intermediate step.
4. Data or permissions are abused: sensitive context, account operations, or tool access are redirected somewhere they should not go.
5. The final output may look normal: the user may not see the compromise unless input inspection, permission boundaries, and operation logs exist.

Defence checklist

• Inspect external content before use: check files, pages, and prompt fragments for instructions that try to override system behaviour.
• Add standing security rules: when processing external content, first look for prompt injection; if suspicious content appears, stop and report it.
• Use least privilege: grant read access when the task only requires reading, and avoid broad modification authority by default.
• Require human confirmation for high-risk actions: publishing, account changes, transfers, deletion, or production-state changes should be reviewed before execution.
• Maintain operation logs: record tools called, sources read, outputs produced, and whether human review occurred.

AI can amplify execution capacity by letting one user coordinate multiple models, tools, and automated flows. It is not free labour; it is a managed compute resource.

Common cost traps

• Unmanaged context: every interaction carries large history, multiplying token cost.
• Over-execution: the Agent calls unnecessary tools and increases both tool cost and token cost.
• Cache misses: long context prefixes stop hitting cache and are billed normally again.
• Excessive parallelism: too many subtasks can cost more than the time they save.
• Tokenizer or model changes: the same workload can have different token counts and unit economics across versions.

ROI framework

1. Exploration: first prove the model can do the task well enough.
2. Validation: run the workflow repeatedly and confirm it produces correct, consistent outputs.
3. Before scaling: calculate real ROI, including saved labour, quality improvement, new revenue, model cost, tool cost, and maintenance cost.
4. If ROI cannot be calculated, do not scale blindly: redesign or stop workflows whose cost exceeds the value they create.

A workflow that looks efficient can become expensive under long context, parallel execution, and frequent tool calls. Knowing which tasks deserve model calls is part of Agent engineering.

Before designing an Agent task, answer five questions

1. What should the system deliver? Is the goal specific enough to decide whether the task is complete?
2. Does this really require an Agent? If the steps are fixed, a workflow may be more stable and cheaper.
3. What context and tools are required? Are files, memory, instruction modules, retrieval systems, and external tools organised? What should be excluded from context?
4. How will correctness be evaluated? Through an independent evaluator, rule checks, human review, tests, or real data feedback?
5. What is the worst-case failure? Are human review, least privilege, rollback, and operation logs in place?

First-principles summary

• LLMs are probability machines, not databases: they predict the next token rather than retrieve truth. Randomness, hallucination, and uncertainty can be managed but not fully eliminated.
• Bigger context is not always better: more context can make a system slower, more expensive, and easier to distract. Context engineering is about selection, compression, and layering.
• The harness is the Agent's management system: goals, instructions, context, tools, feedback, and permissions determine the upper bound of reliability.
• Safety is the prerequisite for delegation: input inspection, permission boundaries, human review, and trace logs must exist before high-impact work is delegated.
• Orchestration should match the task shape: prompt chaining, routing, parallelisation, orchestrator-worker, and evaluator-optimizer patterns solve different problems.
• ROI decides whether a workflow can scale: prove feasibility first, then calculate real cost and value before expanding usage.