Context Engineering as a Harness for AI Agents: Why Organisational Structure Is the Missing Layer

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.

What Is Context Engineering and Why Does It Matter for AI Agents?

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.

Why Does Context Engineering Need an Organisational Layer?

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.

How Does Organisational Structure Provide What Context Engineering Needs?

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.

Why Nested Context Is the Key Design Pattern

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.

Why You Do Not Want Manager or Orchestrator AIs

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.

What Does Organisational Context Change in Practice?

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."

Without organisational context

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.

With organisational context through MCP

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.

Why Does Purpose Matter More Than Instructions for AI Agents?

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).

How Big Is the Organisational Readiness Gap?

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.

Why Do Traditional Approaches to Agent Context Fall Short?

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.

What Do AI Agents Actually Need? Living Organisational Context Through MCP

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 a structured governance process at the pace the organisation learns.

From Context Engineering to Harness Engineering: The Complete Control System

In early 2026, the software engineering community gave a name to the broader system that wraps around an AI agent: the harness. The formula, Agent = Model + Harness, was articulated by Mitchell Hashimoto. Within weeks, OpenAI, Martin Fowler and Thoughtworks, LangChain, and an academic paper by Kim and Hwang published frameworks that share a single insight. The model is not the bottleneck. The environment around the model, the harness, determines whether it produces reliable work.

The evolution is a widening of the lens. From the instruction, to the information environment, to the complete control system.

Context engineering is one dimension of the harness. Harness engineering adds two more: the constraints that govern output, and the feedback loops that refine the structure over time. Kim and Hwang's paper organises this into three dimensions: Context (what informs the agent), Constraint (what governs agent output), and Convergence (the iterative process that refines the structure until it reaches what they call "structural idempotence," a state where re-application produces no further change).

For coding agents, these dimensions are filled by project instructions, linters, and cleanup loops. For organisational agents, the same three dimensions map directly to what role-based governance already provides.

Context: What Informs the Agent

This is what the rest of this article describes in depth: nested purpose, accountabilities, skill documents, governance records, and live project state. The OpenAI team discovered early that giving agents "a map, not a 1,000-page instruction manual" was essential. They moved from a single large AGENTS.md file to a structured docs/ directory that serves as the system of record. In Nestr, the same principle is built into the architecture. An agent reads a skill index first (the map), then loads only the relevant skills for the current action. The nesting is the context architecture.

Constraint: What Governs Agent Output

In coding harnesses, constraints are linters, type checkers, and architectural boundary rules. Organisational governance provides the same function through different mechanisms. Domains give a role exclusive authority over a resource. No other role can interfere without permission granted through a policy. Policies are the organisational equivalent of architectural rules: "The Content Writer role may publish blog posts directly without review" grants authority. "Refund requests above €50 require escalation to the Customer Relations role" restricts it. Accountabilities define what the role is expected to do, creating a persistent mandate the agent reads on every activation.

The parallel is precise. A type checker enforces type safety by preventing invalid operations at compile time. A domain definition prevents an agent from crossing an authority boundary at runtime. Both are structural constraints, not suggestions. In Nestr, domains and policies are defined on roles and circles, visible to the entire organisation, and accessible through MCP. When an agent reads its role context, it inherits these constraints as part of its operating environment.

Convergence: Iterative Refinement Through the Governance Process

In coding harnesses, convergence is cleanup loops and CI/CD pipelines that iterate until the harness passes without changes. In organisations, convergence is the consent-based governance process. The Integrative Decision Making pattern processes every structural change through the same steps: present the proposal, clarifying questions, reactions, amend, test for objections, integrate. In Nestr, this process runs either synchronously in governance meetings or asynchronously between them. Both paths produce the same output: a timestamped structural change, a tested proposal, and an updated role definition.

"Structural idempotence" in organisational terms describes a role definition so clear that re-running the governance process produces no further changes. That is a well-governed role.

The consent bar ensures convergence is efficient. If no one has a reasoned argument that a change would cause harm, it is safe enough to try. Not consensus. Consent. This is faster than agreement-seeking, and it prevents both under-governing (which creates risk) and over-governing (which kills the value).

Every governance change is captured with a timestamp and immediately reflected in the governance records. The convergence loop is continuous. Tensions surface through daily work and tactical meetings. Structural changes are processed through the governance process, in a meeting or async. The updated structure feeds back into the context that every agent reads on its next activation.

What This Means: Nestr as a Harness for Organisational AI Agents

Platforms that make organisational governance explicit, living, and accessible through MCP serve as the harness for organisational AI agents. They provide the same function for role-based work that linters, test suites, and CI/CD pipelines provide for code.

A coding harness typically requires an AGENTS.md file to be updated by hand every time architectural rules change. Organisational governance does not have that problem. When a policy changes in a governance meeting (or asynchronously between meetings), the agent reads the updated policy on its next activation. No one updates a system prompt. The harness is self-updating because the governance structure and the context source are the same system.

How Can Your Organisation Start Building Context for AI Agents?

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 a structured governance process. Roles, purposes, accountabilities, domains, and policies, all visible, all current, all accessible. The 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 through your governance process, 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. The context is the harness.

Frequently Asked Questions

What is context engineering?

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.

How is context engineering different from prompt engineering?

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.

What is harness engineering and how does it relate to context engineering?

Harness engineering is the discipline of designing the complete control system that wraps around an AI agent: context, constraints, and feedback loops. The formula Agent = Model + Harness was formalised in early 2026 through publications by OpenAI, LangChain, Martin Fowler, and an academic paper by Kim and Hwang. Context engineering is one of its three dimensions. The other two are Constraint (what governs agent output) and Convergence (the iterative process that refines the structure over time). For a short overview of harness engineering and how the three dimensions map to governance, see our companion article on harness engineering.

What is the connection between context engineering and organisational governance?

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. Combined with the constraints (domains, policies) and the consent-based governance process, it provides the complete harness.

Why do most agentic AI projects fail?

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.

What is MCP and how does it relate to context engineering?

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.

What is "agent sprawl" and how does organisational context prevent it?

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.

Do we need frameworks like Holacracy or Sociocracy to make this work?

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.

How does this help with EU AI Act compliance?

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.

What is the minimum starting point?

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.

Can we start using AI agents before our organisational structure is fully defined?

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.

Sources and Further Reading

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)

OpenAI, Harness Engineering: Leveraging Codex in an Agent-First World (February 2026)

Martin Fowler, Harness Engineering for Coding Agent Users (2026)

LangChain, The Anatomy of an Agent Harness (March 2026)

Kim & Hwang, Harness Engineering: A Governance Framework for AI-Driven Software Engineering. SSRN (March 2026)

Anthropic, Model Context Protocol (2025)

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)