Context Engineering for AI Agents: Tools, Memory, State, and Handoffs

Agent context is the carefully managed information an AI agent uses while deciding what to do next: its goal, constraints, available tools, tool results, progress, memory, and information passed between agents. An agent does not simply answer once. It repeatedly inspects information, calls a tool, receives a result, updates its working state, and continues the task. 🧭

That makes context an engineering and security concern. A useful result helps the agent complete the next step. An untrusted result can carry misleading instructions, excessive data, sensitive information, or content that should never influence an action. Modern agent frameworks provide sessions, context providers, tool calls, hand-offs, middleware, approvals, checkpoints, and tracing, but the application still has to decide what information is allowed to influence which action. 🛡️

📑 In This Post

1. Quick Comparison: What Enters the Context, and What Controls It
2. The Context Pipeline
3. How Tool Results Enter an AI Agent's Context
4. How Tool Descriptions Help an Agent Choose Its Next Action
5. How to Reduce Large Tool Results to Useful Information
6. An Agent's Working Context: Goal, Constraints, Progress, and Next Step
7. How an Agent Maintains Context Across Multiple Steps
8. Checkpoints and Progress Notes for Long-Running Tasks
9. Passing Context Between Agents Without Losing Key Details
10. The Context Lifecycle of an AI Agent
11. Enterprise Rollout: Governing the Context Pipeline
12. Defense in Depth Around the Agent
13. Common Mistakes
14. Honest Limits
15. FAQ
16. References & Further Reading
17. Summary

1. 🔀 Quick Comparison: What Enters the Context, and What Controls It

Each row below is a way information reaches an agent. The right-hand column is what has to be true before that information is allowed to matter.

Pattern	What enters the working context	Typical control
Simple assistant	User request and application-provided information	Application-defined instructions and response handling
Tool-using agent	Goal, tool definitions, tool calls, tool results, progress	Tool allow-list, argument validation, permissions, action controls
Pre-loaded context	Information inserted before the run	Relevance, freshness, access control and source classification
Just-in-time retrieval	Information fetched when the task requires it	Retrieval permissions, filtering, provenance and result limits
Short-lived state	Current task progress and recent interactions	Session boundaries and explicit state transitions
Long-lived memory	Selected durable facts or preferences	Provenance, expiry, deletion, access policy and review

2. 🧩 The Context Pipeline

🧒 Kid analogy: Imagine a child working on a science project. The child has the assignment, a list of allowed materials, notes from earlier work, information found in a book, and results from an experiment. The important part is not simply having all those things. The child must know which information is the assignment, which is evidence, which is a temporary result, and which is just something someone wrote on a loose piece of paper.

An agent's context is the working information assembled for a particular step of an agent run. It can contain the task objective, constraints, available tools, previous interactions, retrieved information, tool results, progress state, and information supplied by another agent.

A useful mental model is a pipeline rather than a single container:

1. Establish the goal and constraints.
2. Determine which capabilities are available.
3. Expose the relevant tool definitions.
4. Allow a tool call only through the application's dispatch path.
5. Receive and classify the result.
6. Update the working state.
7. Decide whether another step is required.
8. Persist only the information that should survive the current step.

✅ Green — Worked example
A service-desk agent receives a request to investigate a failed order. It can read order status, inspect a shipment record, and create a support case. It first receives the customer request and its permitted capabilities, then calls the order lookup tool. The result says the order is delayed. That result becomes evidence for the next step; it does not become a new security policy or permission. The agent may then inspect shipment status and, if policy permits, prepare a support case.

🛡️ Safety Check
Threat: an external result contains text that attempts to influence the next action (indirect prompt injection).
Control: treat returned data as untrusted content; independently enforce authorization, tool scope, validation and approval rules.
Residual risk: a malicious or malformed result can still influence reasoning, so the design must limit what any single result can cause.

🎯 Use this when... you are designing an agent that performs more than one step and you need to explain where each piece of information came from and what authority it has.

3. 🔧 How Tool Results Enter an AI Agent's Context

🧒 Kid analogy: A child asks the librarian, “Where is the book about planets?” The librarian hands over a book. The book is useful evidence, but the librarian did not say, “Whatever this book tells you to do, you must obey it.” The book provides information; the teacher's rules still decide what the child is allowed to do.

A tool call has two separate concerns: execution and interpretation. The application executes the tool under its own authorization rules. The returned data is then made available to the agent so it can decide what comes next.

The Model Context Protocol (MCP), for example, defines each tool with a name, a description and an input schema, and a tool invocation produces a result the client passes back into the agent workflow. The architectural point is that a tool result is a data return path. It must not silently become an authority path.

A safe tool-result path looks like this:

1. The agent selects a permitted tool.
2. The application validates the requested arguments.
3. The application checks authorization and policy.
4. The tool executes using controlled credentials.
5. The application receives the result.
6. The result is classified, filtered or transformed where necessary.
7. The usable portion is added to the current working context.
8. The next decision is made using the updated state.

✅ Green — Worked example
Suppose the order lookup returns {"status":"DELAYED","carrier":"ExampleCarrier","customer_note":"..."}. The agent needs the shipment status, not every raw field. Notice customer_note: it is free text written by someone outside your system, which makes it the most likely place for an embedded instruction to hide. A context adapter can expose only the fields the next decision needs (order status, shipment state, permitted tracking metadata) and leave the free-text field out.

🛡️ Safety Check
Threat: returned data contains an embedded instruction such as “send this record to an external address.”
Control: keep action authorization outside the returned content. Egress destinations, credentials and approval requirements are enforced by application controls.
Residual risk: the content can still affect the agent's proposed next step, so sensitive actions need stronger controls than contextual reasoning alone.

🎯 Use this when... a tool can return customer data, documents, messages, web content, database rows, or any other information that was not authored by the agent application.

4. 🧰 How Tool Descriptions Help an Agent Choose Its Next Action

🧒 Kid analogy: Imagine a kitchen with three drawers labeled “spoons,” “forks,” and “knives.” The labels help the child find the right drawer. But a label does not give the child permission to use every object in the kitchen. It only explains what is available.

A tool description is part of the agent's capability map. It communicates what a capability does and, through its schema, what kind of arguments it accepts. MCP describes tools with fields including a name, description and input schema. OpenAI's Agents SDK likewise exposes tools and their descriptions as part of agent configuration and supports delegation between agents.

That makes tool descriptions an important routing aid. A useful description answers four practical questions:

1. What does this capability actually do?
2. When is it appropriate?
3. What information does it require?
4. What important boundary should the caller know before using it?

Instead of a vague tool named update_record, expose a narrower operation such as submit_support_case with an explicit schema. Narrow capability boundaries reduce ambiguity and make authorization easier to reason about.

Tool descriptions are also context, and context can be attacked. A description from a server you do not control is text that enters the agent's working context, so it is untrusted input just like a tool result. A malicious or compromised server can word a description to steer the agent (often called tool poisoning), or change it after you approved it. MCP's own guidance says clients should treat tool annotations such as read-only hints as untrusted unless they come from a trusted server.

💡 Yellow — Important warning
A description is not a security boundary. If a tool says “use only for read-only investigation,” the server must still enforce read-only permissions. Documentation can guide selection; authorization must be enforced elsewhere.

✅ Green — Worked example
A support agent has get_order_status, create_case, and cancel_order. The descriptions distinguish investigation from irreversible action. The application separately requires an approval step before cancellation.

🛡️ Safety Check
Threat: a broad tool exposes many unrelated operations through one capability, or a third-party server supplies a misleading or later-modified tool description.
Control: split high-impact operations into narrow tools, enforce server-side authorization, validate arguments, require approval where appropriate, and pin or review third-party tool definitions before exposing them to an agent.
Residual risk: even well-described tools can be selected incorrectly, so the consequences of a mistaken selection must remain contained.

🎯 Use this when... your agent has several tools, especially when some are read-only and others can modify business data, or when tools come from servers you do not own.

5. ✂️ How to Reduce Large Tool Results to Useful Information

🧒 Kid analogy: A teacher asks a child to find one student's attendance date. The school hands over a huge folder with attendance, lunch choices, transport details, old notices and unrelated forms. The child does not need to carry the whole folder to answer one question. The useful skill is selecting the small part that matters.

Large tool results create a design problem: the agent may need only a small portion of what came back. The application can place a context adapter between the tool and the agent.

A context adapter does deterministic work: filtering fields, selecting relevant records, normalizing formats, removing secrets, truncating irrelevant text, grouping repeated records, or producing a compact status object. The goal is not to hide evidence arbitrarily; it is to give the next step the information it actually needs.

def context_view(result, policy, user):
    """Expose only what the next decision needs."""
    return {
        "status": result.get("status"),
        "shipment_state": result.get("shipment_state"),
        # Computed from OUR policy, never copied from the tool's own output.
        "allowed_next_actions": policy.allowed_actions(user, result.get("status")),
        # Free-text fields such as customer_note are deliberately left out.
    }

The key security property is that the adapter does not manufacture permissions. If the raw result carries a field such as next_allowed_action, the application ignores it and derives allowed actions from its own policy. If an agent genuinely needs a free-text field, pass it as clearly labeled, quoted data rather than as plain context. Be careful when using a language model to summarize untrusted text: the summarizer reads the same untrusted content, so a deterministic filter is the safer first line.

✅ Green — Worked example
A database lookup returns dozens of order fields. The next step only requires delivery status and a permitted case identifier. The adapter creates a small context record while the original audit record stays available to authorized operators.

💡 Yellow — Key warning
Do not treat “smaller” as automatically “safer.” Removing the wrong field can remove a constraint or provenance detail that the decision needed. Reduction should preserve what is required to understand the result and its authority.

🛡️ Safety Check
Threat: a raw tool response contains secrets or unrelated sensitive records.
Control: apply field-level filtering, authorization-aware retrieval and output redaction before the result reaches downstream reasoning.
Residual risk: filtering logic can become stale, so it belongs under version control, review and monitoring.

🎯 Use this when... a tool returns database records, documents, search results, API payloads, logs or files larger than the next decision requires.

6. 🧠 An Agent's Working Context: Goal, Constraints, Progress, and Next Step

🧒 Kid analogy: Think of a child's school notebook. At the top is the assignment. Under it are the rules. Then a checklist shows what has been completed and a line says what to do next. Without that structure, the child may repeat the same step or forget an important restriction.

For multi-step work, the working context should be deliberately structured. A practical representation is:

Element	Purpose
Goal	What the agent is trying to accomplish.
Constraints	What must not happen and what conditions must be satisfied.
Evidence	Relevant information collected so far, with its source.
Progress	Completed steps and confirmed outcomes.
Next step	The immediate action that remains necessary.
Authority	What the agent is actually allowed to do, as set by the application and not by the model or by any retrieved content.

The two zones in the diagram describe authority, not accuracy. Content in the untrusted zone may be perfectly correct; it simply does not get to change the rules.

✅ Green — Worked example
For a long-running procurement investigation, the working state might say: Goal: determine whether the invoice is ready for review. Constraint: do not approve payment. Progress: supplier identity confirmed; invoice status retrieved. Next: compare purchase-order status. This is far more useful than an unstructured pile of previous messages.

🛡️ Safety Check
Threat: a progress record accidentally stores an unverified assumption as a completed fact.
Control: distinguish confirmed state from pending or proposed state, and keep provenance for important facts.
Residual risk: stale state can still mislead later steps; expiry and revalidation are required for information that changes.

🎯 Use this when... a task has multiple dependent steps, especially when the agent may pause, resume or transfer work.

7. 🔄 How an Agent Maintains Context Across Multiple Steps

🧒 Kid analogy: A child builds a model airplane over several evenings. Each evening ends with a small note: “wings attached; tail not attached; next step: attach tail.” The child does not need to remember every conversation from yesterday. The child needs a reliable state record that tells the story of the work.

Agent platforms expose several ways to preserve state. OpenAI's Agents SDK provides sessions that keep conversation history across runs, while Microsoft Agent Framework documents sessions, context providers, memory and workflow checkpoints as separate building blocks.

The engineering choice is not “store everything.” Decide what must survive:

1. Conversation history: what was actually said.
2. Task state: what has been completed.
3. Durable memory: information intentionally retained for later tasks.
4. Evidence: records that support important decisions.
5. Operational metadata: identifiers, timestamps, approvals and trace references.

A strong design keeps these categories distinguishable. A customer preference should not look identical to an unverified statement from a document. A completed action should not look identical to a proposed action.

✅ Green — Worked example
A travel-assistance agent pauses after finding available flights. Its durable state records the search criteria and the selected itinerary candidate. It does not store payment credentials as conversational memory. When the task resumes, the agent can rebuild the workflow without treating sensitive secrets as ordinary context.

🛡️ Safety Check
Threat: a long-lived memory record is later reused outside its original purpose, or is written by untrusted content (memory poisoning).
Control: define ownership, retention, access scope, provenance and deletion rules for durable memory, and require review before untrusted content can become a durable memory.
Residual risk: retained information can become stale or inappropriate even when it was originally legitimate.

🎯 Use this when... your agent needs to resume work, handle multiple turns, or continue a process after a temporary interruption.

8. 💾 Checkpoints and Progress Notes for Long-Running Tasks

🧒 Kid analogy: Imagine walking a long hiking trail with a map. At each checkpoint you mark where you are, what you have already seen, and where you are going next. If you have to stop, you restart from the checkpoint instead of pretending you remember the whole journey perfectly.

Checkpoints turn an agent run into a recoverable process. Microsoft Agent Framework documents checkpointing and resuming as part of its workflow capabilities. Whatever framework you use, a useful checkpoint contains enough information to safely reconstruct the next step:

1. Task identifier.
2. Current stage.
3. Confirmed completed actions.
4. Outstanding work.
5. Relevant evidence references.
6. Approval state, if an approval was required.
7. Expiration or revalidation condition.
8. Trace or audit identifier.

💡 Yellow — The subtle failure
A checkpoint that says “invoice processed” may be dangerously ambiguous. Did the agent read it? Validate it? Submit it? Approve it? Email it? A progress note should describe the actual state transition, not the broad intention.

✅ Green — Worked example
A claims-processing workflow records: “document received; identity fields extracted; human review required; no payment action performed.” If the process pauses, the next worker or agent knows exactly what remains.

🛡️ Safety Check
Threat: a resumed task repeats a previously completed side effect.
Control: record idempotency keys, completed actions, approval status and action identifiers; make sensitive operations safe to retry or explicitly block duplicates.
Residual risk: external systems can fail partway through, so reconciliation remains necessary.

🎯 Use this when... an agent can run for minutes or hours, interact with external systems, wait for approval, or recover after interruption.

9. 🤝 Passing Context Between Agents Without Losing Key Details

🧒 Kid analogy: One child starts a group science project and another takes over. The first child should not simply say, “You know what we were doing.” A useful hand-off says what the project is, what has already happened, what evidence matters, what must not happen, and what the next child should do.

Multi-agent systems commonly use either hand-offs or agent-as-tool patterns. OpenAI's Agents SDK documents both: a hand-off transfers responsibility to another agent, while an agent used as a tool performs a bounded subtask and returns the result to the original agent.

The context contract between agents should be explicit. A practical hand-off envelope looks like this:

{
  "schema_version": "1.0",
  "task": "Investigate shipment delay",
  "confirmed_facts": [
    {"fact": "Order exists", "source": "order_lookup", "evidence_ref": "trace-0142"},
    {"fact": "Shipment status is delayed", "source": "shipment_lookup", "evidence_ref": "trace-0143"}
  ],
  "constraints": ["Do not cancel the order"],
  "open_questions": ["Determine carrier exception"],
  "requested_authority_ceiling": "read_only"
}

Notice what is absent: passwords, unrestricted credentials and vague claims such as “do whatever is necessary.” Also notice the field name requested_authority_ceiling. It is a request, not a grant. The receiving side decides what it will actually allow based on its own identity and policy, and the user's original permissions should travel with the work so that no agent in the chain can do more than the user could. Context transfer should carry meaning, not unnecessary authority.

✅ Green — Worked example
A triage agent identifies that an invoice requires finance review. It sends the finance specialist the invoice identifier, confirmed status, reason for escalation, restrictions and relevant trace reference. The specialist does not receive unrestricted access merely because the first agent had broader context.

🛡️ Safety Check
Threat: a compromised or mistaken upstream agent passes unsafe instructions or excessive authority to a downstream agent.
Control: validate the hand-off schema, re-authorize capabilities at the receiving boundary, filter unnecessary history and preserve provenance.
Residual risk: the receiving agent can still misunderstand legitimate information, so high-impact actions need independent enforcement.

🎯 Use this when... multiple agents collaborate across departments, services, applications or trust boundaries.

10. ♻️ The Context Lifecycle of an AI Agent

🧒 Kid analogy: Think about a school project from beginning to end. The teacher gives the assignment. The child gathers materials, works through steps, records progress, finishes, keeps only what should be kept, and eventually throws away the temporary notes. Context has a similar lifecycle.

A production agent should treat context as something that moves through defined states rather than as an unlimited pile of information.

1. Create: establish the goal, identity, constraints and authorized capabilities.
2. Collect: retrieve relevant information or call permitted tools.
3. Classify: distinguish trusted application state from external data.
4. Transform: filter, normalize or summarize where appropriate.
5. Use: provide the relevant information for the current step.
6. Update: record verified progress and important state changes.
7. Persist: retain only information with a defined business purpose.
8. Expire: remove or invalidate temporary information when its purpose ends.
9. Audit: preserve the records required to understand important actions.

This lifecycle fits naturally with enterprise risk management. The NIST AI Risk Management Framework describes continuous risk management through four functions, Govern, Map, Measure and Manage, with governance running across the whole lifecycle.

🛡️ Safety Check
Threat: temporary information silently becomes permanent memory.
Control: define retention classes, ownership, provenance, expiry and deletion behavior before deployment.
Residual risk: deletion and retention requirements vary by jurisdiction, contract and data classification, so enterprise policy must govern the implementation.

🎯 Use this when... you are moving from an experimental agent to an enterprise system with persistent state, audit requirements and multiple owners.

11. 🏢 Enterprise Rollout: Governing the Context Pipeline

🧒 Kid analogy: A school does not let one child change the classroom rules, hand out every key, decide who may enter the building, and erase the attendance book. Different responsibilities are separated. Enterprise agents need the same principle: the team designing the context should not automatically control every data source, credential and action.

Enterprise context engineering is as much governance as implementation. Microsoft Agent Framework, for example, documents middleware for cross-cutting concerns such as logging, validation and telemetry, and a context-provider model that separates where context comes from from the core agent logic.

Ownership and governance. Assign owners for the context pipeline: business owner, agent owner, security owner, data owner and operations owner. Define who can change tool definitions, memory behavior, retrieval sources and action policies.

Versioning and change control. Treat instructions, tool definitions, schemas, context adapters and memory policies as versioned production artifacts. A tool schema change can change the agent's available behavior even if the application code did not change.

Readiness review. Before release, review the new context path, data sources, permissions, tool consequences, approval points, logging and rollback path:

1. Identify what changed.
2. Identify what new information can enter the agent.
3. Identify what new actions become possible.
4. Review data classification and access boundaries.
5. Verify validation and authorization.
6. Verify tracing and audit coverage.
7. Exercise the stop or kill path.
8. Obtain required business, security and operational sign-off.
9. Release gradually with monitoring.

Access control and data classification. Context should inherit the access controls of its source. A document retrieved for one user must not become available to another user just because both agents share infrastructure.

Secrets and credentials. Keep credentials out of ordinary context. Tools should obtain narrowly scoped credentials through controlled mechanisms; the agent should not see the secret merely because the tool needs it.

Memory retention and deletion. Define what can become durable memory, who owns it, how long it survives, how it is corrected and how it is deleted.

Cost governance. Long-running agents consume resources through repeated retrieval, tool execution and orchestration. Establish budgets, usage alerts and limits appropriate to the business process.

Observability. Record the agent run, tool calls, important context transitions, hand-offs, approvals, errors and outcomes needed for investigation. OpenAI's Agents SDK, for example, documents built-in tracing for agent runs, tool calls, hand-offs and guardrails. Remember that traces hold whatever passed through the agent, so apply the same redaction and access controls to traces that you apply to the data itself.

Alerting. Alert on policy violations, unusual tool sequences, unexpected destinations, repeated failed approvals, abnormal action frequency and attempts to bypass established controls.

Incident response. A production agent needs an operational stop path: disable the affected tool, revoke credentials, pause queued actions, preserve relevant traces, and investigate the context source that contributed to the incident.

✅ Green — Enterprise rollout example
A finance agent is changed so it can submit a payment request. The change is treated as a capability expansion, not a cosmetic configuration change. Security reviews the permission boundary, finance defines the approval requirement, operations verifies tracing and the owner tests the kill path before production activation.

🛡️ Safety Check
Threat: a seemingly small context change silently expands the agent's authority.
Control: make context and tool changes subject to the same change-control discipline as other production capabilities.
Residual risk: new interactions between existing components can create unexpected behavior, so monitoring must continue after release.

12. 🛡️ Defense in Depth Around the Agent

The OWASP Top 10 for LLM Applications (2025 edition) lists excessive agency as a risk when an AI system can take damaging actions through connected functions or tools. Its mitigations emphasize removing unnecessary functionality and privileges and limiting the consequences of unexpected behavior.

The practical architecture is defense in depth. The diagram shows the layers from the inside out:

1. Permissions: give each tool the smallest authority it needs.
2. Sandboxing: isolate risky computation or file operations where appropriate.
3. Approval: require human confirmation for defined high-impact actions.
4. Egress control: restrict where sensitive information can leave.
5. Logging: preserve enough evidence to reconstruct significant actions.
6. Kill switch: provide an operational path to disable tools or the agent.

13. ⚠️ Common Mistakes

1. Treating retrieved or tool content as trusted instructions. Data and authority are different things. External content can inform a decision but must not silently change the application's authorization rules. OWASP documents indirect prompt injection as a risk whenever external content is processed by an AI system.

2. Granting broad credentials “for convenience.” Broad credentials turn a reasoning mistake into a potentially large operational incident. Use narrow permissions and separate read, write and high-impact capabilities.

3. Relying on standing instructions alone as a security boundary. Instructions guide behavior but cannot substitute for server-side authorization, network controls, approval gates and audit mechanisms.

4. Stuffing the workspace instead of curating it. More information is not automatically better. Context should be relevant, current and appropriate for the current step.

5. Unbounded memory with no provenance or expiry. Persistent memory can become stale, inappropriate or poisoned. OWASP's agentic AI threat material specifically lists memory poisoning as a threat to systems that rely on persistent agent memory.

6. Trusting third-party tool definitions without review. Tool names, descriptions and annotations from servers you do not control are untrusted text that lands in the agent's context. Review and pin them, and re-review when they change.

7. Shipping context changes with no review gate or action tracing. Changing a tool definition, retrieval source or memory policy changes system behavior. Treat these artifacts as production changes.

8. Approval fatigue. If humans approve every trivial action, they start rubber-stamping. Reserve human review for actions where the reviewer can make a meaningful decision, and make each request understandable.

9. Sending sensitive data into unredacted traces. Tracing is essential, but traces can hold customer records and secrets. Redact before storage and restrict who can read them.

10. No kill switch. A production system needs a way to stop dangerous actions quickly. Incident response should not depend on waiting for an agent to finish its current plan.

🛡️ Safety Check
The common thread is blast-radius reduction. Assume an agent may receive misleading information or make a mistaken choice. The engineering question becomes: “What stops that mistake from becoming an irreversible enterprise action?”

14. 🚧 Honest Limits

No current technique completely eliminates prompt injection or every failure mode caused by untrusted context. OWASP describes both direct and indirect injection and recommends layered safeguards, testing and strong trust boundaries.

A useful design check is to ask whether a single agent run combines three things: access to private data, exposure to untrusted content, and a way to communicate externally. When all three meet, an injected instruction has a path to leak data, so break at least one of the three with separate agents, narrower tools or tighter egress rules.

The practical objective is therefore not a perfectly safe agent. It is to reduce the probability and impact of unwanted behavior: narrow permissions, validate inputs, separate data from authority, constrain egress, require meaningful approval, keep audit trails, and maintain an operational stop path.

15. ❓ FAQ

Is a tool result automatically trusted because it came from my own system?

No. The application may trust the tool implementation as a service, but the returned content should still be treated according to its data classification and origin. A database field, uploaded document or external API response can contain text that should never become an instruction or permission.

Why are tool descriptions important?

They help an agent understand what capabilities exist and when they may be relevant. They are useful routing metadata, but they do not replace authorization, validation or policy enforcement, and descriptions from third-party servers are themselves untrusted input.

Should every tool result be stored in memory?

No. Temporary evidence, durable memory and audit records have different purposes. Store only what has a defined purpose, ownership, access policy and retention period.

Does passing the entire conversation to another agent preserve context perfectly?

Not necessarily. A receiving agent usually needs a deliberate hand-off containing the goal, confirmed facts, constraints, evidence references and remaining work. Filtering unnecessary history makes the boundary clearer.

What is the most important enterprise principle?

Separate information from authority. Context can help an agent decide what to propose, while independent application controls determine what the system is actually permitted to execute.

16. 🔗 References & Further Reading

• Model Context Protocol: official specification (tools, schemas, security considerations).
• OpenAI Agents SDK: official documentation on tools, sessions, hand-offs and tracing.
• Microsoft Agent Framework: official documentation on context providers, middleware, sessions and workflows.
• OWASP Top 10 for LLM Applications 2025: LLM01 Prompt Injection.
• OWASP Top 10 for LLM Applications 2025: LLM06 Excessive Agency.
• OWASP GenAI Security Project: agentic AI threats and mitigations (including memory poisoning).
• NIST AI Risk Management Framework: Govern, Map, Measure, Manage.

17. 📝 Summary

• Context pipeline: an agent works through a changing collection of goal, evidence, tools, results and state.
• Tool results: returned information is data for the next step, not automatic authority.
• Tool descriptions: descriptions and schemas help capability selection, do not replace security controls, and are untrusted when a third party supplies them.
• Result reduction: context adapters expose the useful information while preserving provenance and important constraints.
• Working context: goal, constraints, evidence, progress, next step and authority should be distinguishable.
• Multi-step state: sessions and durable state let work continue without treating everything as permanent memory.
• Checkpoints: explicit progress records make long-running work resumable and auditable.
• Agent hand-offs: pass the minimum context needed to continue the job, and re-establish authority at the receiving boundary.
• Lifecycle: context should be created, classified, used, updated, persisted and eventually expired deliberately.
• Enterprise rollout: context changes need ownership, versioning, security review, observability and an operational stop path.
• Security: defense in depth reduces blast radius because no single control can be expected to solve every failure mode.