Context engineering is the discipline of designing dynamic systems that provide AI agents with the right information, in the right format, at the right time. It has rapidly become the defining challenge in agentic AI, overtaking prompt engineering as the discipline that determines whether agents succeed or fail. Most context engineering work today focuses on what happens within a single agent's thread: prompt design, tool definitions, memory, retrieval. But for any agent operating inside an organisation, the richest source of context is the organisation itself. Its roles, its purposes, its authority boundaries, its governance records, its living policies. For practitioners of role-based governance systems like Holacracy and Sociocracy, structuring this kind of clarity is familiar work. What is new is that the same principles that make human teams effective turn out to be exactly what AI agents need to operate with judgement rather than just follow instructions.
Context engineering is the practice of building systems that curate and maintain the optimal set of information available to an AI agent at any given moment. It matters because the instruction, the prompt, turned out to be a small fraction of what determines whether an agent acts well. Braintrust's analysis of production AI applications found that 67.6% of tokens come from tool definitions and responses, not from the prompt (Braintrust, 2025). For any organisation deploying agentic workflows, context engineering is now the discipline that separates agents that execute tasks from agents that exercise judgement.
The term gained mainstream traction in mid-2025 when Shopify CEO Tobi Lütke described it as "the art of providing all the context for the task to be plausibly solvable by the LLM." Andrej Karpathy amplified the framing, calling it "the delicate art and science of filling the context window with just the right information for the next step." By September 2025, Anthropic had formalised it as a core engineering discipline, describing it as "curating and maintaining the optimal set of tokens during LLM inference" (Anthropic, September 2025).
Harrison Chase at LangChain frames it as building systems that provide "the right information and tools, in the right format, at the right time" (LangChain, June 2025). Google's Agent Development Kit treats context as "a compiled view over a richer stateful system." These definitions point to the same insight: context is not static information you paste into a prompt. It is a dynamic, layered architecture that changes with every decision. The system prompt, the tools available, the memory of past interactions, the retrieval of relevant knowledge, the current state of work. All of it, carefully curated.
Context engineering frameworks approach the problem from different angles. Anthropic focuses on system prompts, tools, memory, and retrieval. Google's Agent Development Kit uses tiered storage: working context, session state, memory, and artifacts. LangChain thinks in terms of dynamic assembly from multiple sources. There is no single canonical model, but all of them focus on delivering context to an individual agent within a single thread or task.
That works well for standalone agents. But the moment an agent operates inside an organisation, alongside other roles, within authority boundaries, serving a shared purpose, a different kind of context becomes essential. Not the context you engineer per prompt, but the context the organisation already holds: who is responsible for what, what authority each role has, what policies constrain decisions, how the structure has evolved, and what is happening across teams right now. This is not information you can paste into a system prompt once. It is a living structure that changes through governance meetings, project updates, and tension processing.
For practitioners of role-based governance like Holacracy and Sociocracy, this kind of structural clarity is the foundation everything else is built on. It works for AI agents for the same reason it works for human teams: a role-filler, whether a person or an agent, cannot make good decisions without knowing who they are, what they are responsible for, and what the organisation expects of them.
The context that engineers are trying to deliver to agents is not something you build from scratch per agent. It already exists inside a well-governed organisation. In a nested governance system, where a workspace contains circles, circles contain roles, roles contain projects, and roles carry their own skill documents and policies, all of that context is structured, queryable, and accessible through MCP. The nesting IS the context architecture.
Here is what an agent needs, and how an organisational operating system already provides it:
Role-based governance systems like Holacracy and Sociocracy have been building these structures for decades, not for AI agents, but for the same fundamental reason: a role-filler, human or AI, cannot make good decisions without knowing who they are, what they are responsible for, what authority they have, what the organisation has learned, and what is happening around them right now.
The core insight is not just that organisational context exists. It is that it is nested. In Nestr, everything is a nest inside other nests: a workspace contains circles, circles contain roles, roles contain projects, projects contain tasks, roles contain skills, skills can reference other skills through index files. This nesting is not incidental. It is the architecture that makes context engineering work at scale.
Google's Agent Development Kit, one of the most technically sophisticated multi-agent frameworks available, explicitly prevents "context explosion" in multi-agent systems by scoping what each sub-agent sees based on hierarchy level (Google Developers Blog, December 2025). Microsoft Azure's AI Agent orchestration patterns follow a similar principle, recommending hierarchical context boundaries to prevent agents from drowning in irrelevant information (Microsoft Azure, February 2026). This is precisely how nested governance structures work: a workspace-level agent sees broad organisational context, a circle-level agent sees its team's purpose and role summaries, and a role-level agent sees its full accountabilities, domain knowledge, and active tasks.
In practice, this nesting means an agent does not need to load the entire organisation into its context window. It reads a boot sequence to understand the basics, checks a skill index to see what knowledge is available, inspects its current open work, and loads only the specific skills relevant to the action at hand. For every decision, the agent can navigate up (what is my circle's purpose? what is the organisation's purpose?) or down (what are the details of this specific policy? what did the last governance meeting decide about my domain?) to get exactly the context it needs. The nesting is the context architecture.
One of the most common patterns in multi-agent architectures is the "orchestrator" or "manager" agent: a central AI that delegates tasks to sub-agents, reviews their output, and makes final decisions. This pattern is borrowed directly from traditional management hierarchies. And it has the same weakness in AI systems that it has in human organisations: the manager has less context about the actual work than the person (or agent) doing it.
In self-organisation methodologies like Holacracy and Sociocracy, the core principle is that the role closest to the work should hold the authority to make decisions about it. Not because the role-filler is smarter, but because they have the most specific, high-resolution context about their area. A content strategist knows more about editorial sequencing than a general manager. An SEO specialist knows more about crawlability than a project lead. Authority follows context, not hierarchy.
With AI agents, this principle becomes even more important, for one reason that did not exist in the human-only world: the model is equally capable in every role it fills. When a human team distributes authority, there is always a question of skill variation. Some people are simply more capable than others, and that can justify concentrating decisions at a higher level. With AI agents, that argument disappears. The same model powers the SEO Specialist, the Copywriter, the Developer, and the Content Strategist. The only thing that differentiates their performance is context. Give a role-level agent deep, specific context about its accountabilities, its domain, its skill documents, and its active projects, and it will make better decisions about that work than any "manager" agent that sees a shallow summary of everything.
This is why a nested governance structure works better than a hierarchical orchestrator for multi-agent systems. Instead of one manager agent trying to hold a broad, shallow view of everything, each role-level agent holds a deep, specific view of its own work. Coordination happens through shared purpose (the circle's purpose cascades to all its roles), through policies (explicit rules everyone operates by), and through structured meetings (tactical meetings for operational coordination, governance meetings for structural changes). No single agent needs to be "in charge." The structure itself provides the coordination.
The organisations that will get the most value from AI agents are not the ones that build the most sophisticated orchestration layers. They are the ones that build the clearest context at each role, so that every agent can act with full authority within its area. Context is the new hierarchy.
An agent with organisational context does not just know more. It reasons differently. When its context window contains nested purpose, living governance records, and shared awareness of what other teams are working on, it shifts from task execution to contextual judgement. The difference is not better instructions. It is a richer information environment.
To see this concretely, consider a Customer Success Agent operating at a creative SaaS platform. It receives this message from a new user:
"I've been trying to connect my custom domain for three hours and it's still not working. This is way more complicated than I thought it would be."
The agent has its system prompt, a connection to the knowledge base, and conversation history. It identifies the topic (domain setup), retrieves the relevant help article, and responds:
"Here is our step-by-step guide to custom domains. Please follow these instructions and let us know if you need further assistance."
Technically correct. Contextually inadequate. The user is frustrated and on the verge of abandoning the platform.
The same agent can now access its nested purpose, its circle's current projects, and the governance records that define its authority. Here is how its reasoning changes.
Purpose check. The agent's role purpose is "ensuring every new user feels capable, supported, and ready to build." Its circle's purpose is "bridging the gap to the customer's first success." The organisation's purpose is "helping independent creators out-compete the giants." This is not a documentation request. This is a user at risk of giving up before they ever create anything.
Context check. The agent sees that the engineering team's current project includes a known DNS propagation issue affecting this exact scenario. It also sees that its domain includes read access to DNS settings, with a policy allowing it to make simple configuration fixes directly, a policy adopted in last month's governance meeting after a similar tension was raised.
Accountability check. One of its accountabilities reads: "Monitoring new user progress and proactively intervening when engagement signals indicate risk of abandonment."
The response shifts entirely:
"I've looked into your account and found the issue. It's a known DNS propagation delay that's been affecting several new users this week. I've gone ahead and applied the fix on our end, so your domain should be live within the next few minutes. I also noticed your landing page is nearly ready. Here's a quick-launch checklist to help you go live tonight."
That shift is not caused by a better model. It is caused by what is in the context window. Each row adds organisational context that no prompt can replicate, because it is living, evolving, and shared across the organisation.
Task instructions degrade over a decision chain. Purpose persists. Academic research on multi-agent systems has documented the compounding error problem: an agent making ten sequential decisions at 95% accuracy per step has only a 60% probability of getting the entire sequence right (arXiv, January 2026). For autonomous AI agents operating in real organisational workflows, where decision chains are often much longer, this is the critical vulnerability that purpose-driven context mitigates.
When an agent has access to the nested hierarchy of purpose, from its own role through the team's purpose to the organisation's reason for being, each decision is filtered through "does this serve the intended outcome?" rather than just "did I follow the rule?"
The Customer Success Agent in the scenario above did not follow more instructions. It had better context for why it exists, and that purpose filtered its judgement at every step.
MIT Sloan Management Review recently observed that agents do not just act, they need to understand why they are acting. Purpose-binding ensures that an AI's decisions align with the organisation's mission, not just with efficiency metrics (MIT Sloan, 2025).
If organisational context is the missing layer, the question becomes: how many organisations actually have this context in a form their agents can access? The answer, based on data from every major analyst firm, is very few. Only 21% of organisations report having a mature framework for governing autonomous agents, even as 74% plan to deploy agentic AI within two years (Deloitte, 2026).
Deloitte's framing captures it sharply: bolting autonomous agents onto operating models designed for human workers is like fitting a jet engine to a bicycle (Deloitte Insights, 2026). McKinsey recommends that onboarding agents is more like hiring a new employee than deploying software. Harvard Business Review recently echoed this, arguing that organisations need a structured onboarding plan for AI agents that mirrors how they would integrate any new team member (Harvard Business Review, March 2026).
These are not technology problems. They are context problems. And the context that is missing is organisational.
Most organisations treat organisational context as static content rather than as a living system. They paste company information into a system prompt, add human approval layers, or produce a one-off documentation project. All three approaches share the same flaw: the context is frozen at the moment it was written, while the organisation continues to evolve. The agent operates on an outdated map.
Here is how each approach breaks down in practice.
Static system prompts. The most common approach is to paste organisational context into a system prompt: a paragraph about the company, a list of rules, a description of the agent's responsibilities. Whether the agent is built on OpenAI's Assistants API, Amazon Bedrock Agents, or Microsoft Copilot Studio, the pattern is the same. This works for simple agents with narrow tasks. It breaks down the moment an agent needs to exercise judgement, because every time a policy changes, a project launches, or a role's authority expands through a governance meeting, the system prompt stays the same. The agent's understanding of the organisation becomes more wrong with every passing week.
Adding oversight layers. Some organisations respond by adding human approval steps on top of every agent action, often tracked through Jira or Asana tickets. This feels safe but recreates the bottleneck the agent was supposed to eliminate. What is needed is not someone watching every move. It is clarity about what the agent is authorised to do within its domain, and a governance process for evolving those boundaries as the organisation learns.
One-off documentation projects. Others produce a comprehensive document in Confluence, Notion, or Google Drive describing the organisation's structure, roles, and policies. The document is accurate on the day it is written and begins decaying immediately. Three months later, the documentation describes an organisation that no longer exists.
The common thread across all three approaches is that they confuse a snapshot for a system. The context an agent needs is not a document written once and filed away. It is a governance structure that evolves through structured meetings, at the pace the organisation learns. When the structure changes, the context changes with it, automatically, because they are the same thing.
AI agents need a living organisational structure where governance records, role definitions, project state, and policy decisions are current, explicit, and accessible through a standard protocol. Model Context Protocol (MCP), originally developed by Anthropic and now an open standard governed by the Linux Foundation, provides this bridge. It connects AI assistants like Claude, ChatGPT, and Gemini directly to your actual working organisation, not a static knowledge base.
When your organisational structure is accessible through MCP, your AI agents can access:
DataHub recently introduced a useful distinction: context engineering is per-application, developer-level work; context management is enterprise-wide organisational capability. Their analogy is apt: context engineering is like each development team writing their own authentication system, while context management is like implementing enterprise single sign-on.
We think organisational governance structures are the enterprise SSO of agent context. A single, authoritative source of truth about who is responsible for what, within what boundaries, and how those boundaries evolve. Not a static document. A living system, accessible through MCP, that evolves through structured governance meetings at the pace the organisation learns.
The foundation is not a technology project. It is an organisational capability. Make your structure explicit, treat it as a context architecture, and connect it through MCP. These three steps can start now, regardless of where you are in your agentic AI journey.
It is my belief that the organisations that make their structure explicit, treat it as a context architecture, and connect it to their agents will not just deploy better agents. They will build organisations that can genuinely sense and respond to the world around them, with every role-filler, human and AI, operating from a shared understanding of purpose.
First, make your organisational structure explicit. Not in a one-time documentation project, but as a living system of governance records that evolve through structured governance meetings. Roles, purposes, accountabilities, domains, and policies, all visible, all current, all accessible. The governance process is consent-based, not consensus-based: if no one has a reasoned argument that a change would cause harm, it is safe enough to try. This is the foundation. Without it, every AI agent you deploy is operating with an incomplete map.
Second, treat that structure as a context architecture. Every role definition, every policy, every governance decision is structured context that AI agents need to operate with judgement. When you update a policy in a governance meeting, you are simultaneously updating the context that guides your agents. One organisational operating system for everyone, carbon-based and silicon-based alike.
Third, connect it. Model Context Protocol exists today. AI assistants can already connect directly to organisational systems. The question is not whether the technical bridge exists. It does. The question is whether you have built anything worth connecting to. Even a solo founder building an AI agent team can start with a single role connected through MCP and expand from there.
At Nestr, we have spent the better part of a decade building the organisational operating system that makes this possible: governance records, role clarity, project tracking, structured meetings, and a living organisational context accessible through MCP. What makes human teams work well (explicit roles, clear authority, living policies, a shared understanding of purpose) is exactly what AI agents need to work well too. The structure is the context.
Context engineering is the discipline of designing dynamic systems that provide AI agents with the right information, in the right format, at the right time. It goes beyond prompt engineering by recognising that the instruction is a small part of what determines agent quality. The entire information environment, tools, memory, retrieval, state, determines whether an agent makes good decisions.
Prompt engineering focuses on crafting the right instruction. Context engineering focuses on building the system that delivers the right information surrounding that instruction. Braintrust's analysis found that 67.6% of tokens in production AI applications come from tool definitions and responses, not from the prompt itself. The prompt was always a small piece of the picture.
Context engineering frameworks focus on delivering information to an agent within a single thread. Organisational governance provides the shared context that every agent and every human draws from: nested purposes, domains and policies, role accountabilities, skill documents, governance records, and live projects and tensions. Making this structure explicit and accessible through a protocol like MCP is context engineering at the organisational level.
Not because of technology limitations. Gartner predicts over 40% of agentic AI projects will be cancelled by end of 2027 due to escalating costs, unclear value, and inadequate governance. RAND found that the number one root cause of AI project failure is misunderstandings about purpose and domain context. The context is the problem, and the missing context is organisational.
MCP (Model Context Protocol) is an open standard, now governed by the Linux Foundation, that allows AI agents to connect directly to external systems and data. When your organisational structure (roles, projects, governance records, meeting outcomes) is accessible through MCP, your AI agents can read and act on your actual working agreements instead of operating from static instructions.
Agent sprawl happens when multiple people independently set up AI agents without shared visibility or coordination. Agents duplicate each other's work, give customers conflicting answers, and gradually accumulate access beyond their original scope. When every agent connects to the same organisational context, roles are visible, boundaries are clear, and overlaps surface before they cause damage.
No. The principles described here, explicit roles, clear authority boundaries, living policies, structured governance, and shared organisational context, do not require any specific framework. They are practical organisational hygiene that benefits any company deploying AI agents. Holacracy and Sociocracy are well-developed implementations of these principles that have been refined across thousands of organisations over decades, and they provide ready-made patterns. But the concepts stand on their own merit.
The EU AI Act requires documented governance, continuous risk management, human oversight, and traceability for high-risk AI systems. When every governance decision, role change, and policy update is tracked from day one as a natural byproduct of how you work, you build compliance evidence continuously rather than scrambling to produce it before a deadline.
One team. A clear set of roles with purpose, accountabilities, and policies. A regular governance rhythm to evolve the structure. Connect your first AI agent through MCP so it operates within defined boundaries from day one. The same foundation that makes the first agent successful makes every subsequent agent faster to deploy.
Yes, but with intention. You do not need a perfectly documented organisation before deploying your first agent. What you do need is clarity about the specific role that agent will fill: its purpose, its accountabilities, its domain of authority, and the policies that constrain it. Start with one role, get the pattern right, and expand from there.
Tobi Lütke, Context Engineering over Prompt Engineering (June 2025)
Andrej Karpathy, Context Engineering Endorsement (June 2025)
Anthropic, Effective Context Engineering for AI Agents (September 2025)
Harrison Chase / LangChain, The Rise of Context Engineering (June 2025)
Google Developers Blog, Context-Aware Multi-Agent Framework for Production (December 2025)
Microsoft Azure, AI Agent Orchestration Patterns (February 2026)
Braintrust, The Canonical Agent Architecture: A While Loop with Tools (2025)
DataHub, Context Management: The Missing Piece for Agentic AI (2026)
RAND Corporation, Root Causes of Failure for AI Projects (2024)
McKinsey, One Year of Agentic AI: Six Lessons (September 2025)
McKinsey, The Agentic Organisation (September 2025)
Deloitte, State of AI in Enterprise 2026
Deloitte Insights, Rethinking Operating Models for Humans with Agents (2026)
MIT Sloan Management Review, 5 Heavy Lifts of Deploying AI Agents (2025)
Harvard Business Review, Create an Onboarding Plan for AI Agents (March 2026)
arXiv, Agentic AI: Architectures, Taxonomies, and Evaluation (January 2026)
.png){kind=logo}
