DEV Community: Sahil David

I Believe We Need a New Class of Agents: Officers

Sahil David — Tue, 31 Mar 2026 11:10:37 +0000

Every major AI agent framework ships with the same assumption baked in: if the agent completes the task, the job is done.

That assumption is wrong. And it is going to cost people.

The gap we should be talking about

Right now, across every serious AI project, the architecture looks roughly the same. You have agents. Those agents have tools. And you have an orchestrator deciding which agent does what, in what order, to get a task done.

The orchestrator is good at its job. It routes. It sequences. It delegates. It optimises for one thing: task completion.

But here is the question no one is asking.

Who is checking whether the completed task actually serves the person who requested it?

Not whether it ran successfully. Not whether the code compiles or the email was sent. Whether the outcome is in your best interest.

That layer does not exist. Not in any agent framework shipping today.

Orchestration is not governance

This is a distinction that matters more than most people realise.

An orchestrator decides what your agents do. It plans, delegates, sequences. It is a project manager.

But a project manager is not a fiduciary. A project manager does not ask: "Should we be doing this at all?" They ask: "What is the most efficient way to get this done?"

Those are very different questions.

Think about what happens when you give a coding agent a simple instruction: "Fix the login bug." The agent fixes it. Then it notices the auth module could use some refactoring. So it starts refactoring. The orchestrator sees a subtask and routes it. Nobody flags that you asked for a bug fix and your agent just expanded scope into a critical system.

Or this. You have two agents running in parallel. Agent A updates an API schema. Agent B is building frontend components against the old schema. The orchestrator gave them both valid tasks. Neither agent can see what the other is doing. By the time you notice, both have been working at cross purposes for twenty minutes.

Or this. Your agent finishes a task and wants to push directly to main. On your solo project, fine. On a team repo with PR norms, that is a reputational risk the agent has no concept of.

The orchestrator did its job in every one of these scenarios. The agents completed their tasks. And the outcome still did not serve you.

What is missing is fiduciary duty

The concept comes from corporate law. An Officer of a company owes a fiduciary duty to the entity they serve. Not a duty to complete tasks. A duty of loyalty, care, and good faith toward the principal's interests.

That is exactly what AI agent systems need.

Not another orchestrator. Not smarter agents. Not better prompts. A dedicated supervisory layer whose only job is to ask: "Does this action serve my principal?"

I am calling this layer an Officer.

How an Officer works

An Officer sits between your agents and the outside world. Every action an agent wants to take routes through the Officer first. Nothing reaches the principal or triggers an external action without a ruling. The Officer does not do the work. It governs the work.

On every proposed action, the Officer makes one of four rulings:

Approve. The action clearly serves your interests and is within bounds. Proceed.

Modify. The action is directionally right but needs adjustment. The Officer rewrites the parameters before execution.

Escalate. The action is ambiguous, high-stakes, or outside the Officer's confidence. It asks you directly before proceeding.

Veto. The action violates your constraints, conflicts with your interests, or exceeds authority. Blocked, with a reason logged.

This is not a static rule engine. The Officer reasons about context. It weighs tradeoffs. It knows that a git push means something different on a solo repo than on a team codebase. It knows that running the full integration test suite for a one-line CSS fix is a waste of your time and money. It knows that when your agent starts expanding scope, that is a decision you should be making, not the agent.

Why this is not the same as guardrails

Guardrails are rules. They are binary. If X, block. If Y, allow.

An Officer is judgment. It has the full picture. It knows your stated interests, your authority boundaries, what every agent in the system is doing, and what has happened so far in the session. It makes contextual decisions, not pattern matches.

And critically, it knows when to decide and when to defer. A guardrail never asks you for input. An Officer escalates when the stakes are high enough or the answer is genuinely ambiguous. That is not a limitation. That is the feature.

Why this matters now

I did not arrive at this from theory. While building multi-agent systems I kept hitting the same wall.

I would architect a system where every agent was well-scoped, every tool was correctly wired, every orchestration flow was clean. And still, the system would produce outcomes that technically completed the task but missed the point. An agent would make a decision that was locally correct but globally wrong. Two agents would work at cross purposes because neither could see the full picture. Actions that should have been flagged would sail through because no layer existed to flag them.

The pattern was always the same. The agents were fine. The orchestration was fine. What was missing was someone asking: "But should we?"

Here is where we are in the stack. MCP standardised how agents talk to tools. That was Layer 1. A2A is standardising how agents talk to each other. That is Layer 2. Shared memory and context protocols like Akashik are emerging as Layer 3.

But there is no Layer 0. No foundational layer that governs whether the work being done across all those layers actually serves the human at the top.

Officers is Layer 0. The governance layer that should have existed before any of the others.
The frameworks are maturing fast. Agents are getting more autonomous by the month. And the window between "agents that need hand-holding" and "agents that can cause real damage unsupervised" is closing faster than most people realise. The time to build the accountability layer is before you need it, not after the first incident.

What is next

Officers should exist as both an open specification and an SDK. That is where I am taking this.

My initial thoughts: The easiest way to start is an officer.md file in the root of your project. It defines who the principal is, what their interests are, what agents are allowed to do autonomously, what requires approval, and what is off-limits. That single file gives any Officer-aware system enough context to govern your agents on your behalf.

The SDK wraps any agent system's tool execution layer so the Officer can evaluate actions at runtime using that context.

The spec will be open. Not because governance should be a product moat, but because it should be infrastructure. The same way MCP became the standard for tool connectivity because it was open, Officers should become the standard for agent accountability because anyone can adopt it. If your agents can act, they should be governed. That should not depend on which vendor you chose.

Every agent system today is optimised for capability. How fast can the agents move. How many tools can they access. How complex a task can they handle.

Let’s optimise for trust. For the confidence that what your agents produce actually serves you. For the certainty that when you step away, the system is not just completing tasks but protecting your interests.

That is what Officers changes. And I believe it is the most important missing layer in the entire agent stack. And if it is not this, then what is the layer that makes you trust your agents when you are not watching?

~ Sahil David

The Missing Layer in the Agent Stack: Why I Wrote a Shared Memory Protocol for AI Agents

Sahil David — Thu, 19 Mar 2026 17:41:24 +0000

AI agents can call tools. They can talk to each other. But they can't remember together.

I found this out the hard way, and that's why I built the Akashik Protocol.

The moment it broke

A few months ago, I ran an experiment. Five AI agents, one research task. A researcher, an analyst, a strategist, a writer, and a reviewer. They could call tools via MCP. They could pass messages. On paper, it should have worked.

Here's what actually happened.

The strategist made a recommendation based on data that the researcher had already corrected two steps earlier. The writer produced a section that directly contradicted the analyst's findings. And nobody, not the agents, not the system, caught it.

The models were fine. The memory layer was missing.

The gap

I went looking for a protocol that solved this. Here's what I found:

MCP (Model Context Protocol) standardises how agents call tools, read a file, query a database, and invoke a function. Brilliant at what it does.

A2A (Agent-to-Agent) standardises how agents message each other, send tasks, receive results, and stream progress. Also brilliant.

But what happens after the call:

Where do findings go once an agent produces them?
How does context accumulate across agents and turns?
What happens when two agents arrive at contradictory conclusions?

Every team building multi-agent systems is solving this from scratch. Custom state management. Ad-hoc memory. Fragile glue code that breaks the moment you add a fourth agent.

Akashik: the third layer

Today I'm publishing the Akashik Protocol ~ an open specification for shared memory and coordination between AI agents.

Think of it as the missing third layer in the agent stack:

Layer	Protocol	What it handles
Tool access	MCP	Agent ↔ Tool
Messaging	A2A	Agent ↔ Agent
Memory	Akashik	Shared memory & coordination

These aren't competing protocols. They're complementary layers of the same stack.

Three ideas at the core

1. Intent is mandatory

You cannot write to the Akashik Field (the shared memory space) without declaring why. The intent field is required on every single write.

await researcher.record({
  type: 'finding',
  content: 'European SaaS market growing at 23% CAGR',
  intent: {
    purpose: 'Validate market size for go-to-market strategy',
    question: 'Is the market large enough to justify entry?'
  }
})

Any agent ~ or any human ~ can look at any finding and immediately understand what question it was answering. You get a reasoning chain for free.

2. Attunement, not search

Agents don't query a database. They declare who they are, their role, active task, and context budget, and the protocol figures out what's relevant.

const context = await strategist.attune({
  scope: {
    role: 'strategist',
    max_units: 10
  },
  context_hint: 'Drafting competitive positioning section'
})

// context.record[0].relevance_score → 0.85
// context.record[0].relevance_reason → 'Recent finding from researcher. Market sizing relevant to strategy.'

Every returned unit includes a relevance score and a human-readable reason for why it was surfaced. Context finds the agent, not the other way around.

3. Conflicts are first-class

When two agents arrive at contradictory conclusions, the protocol detects it, creates a structured Conflict object, and surfaces it in every relevant ATTUNE response. Nothing gets silently overwritten.

await researcher2.record({
  type: 'finding',
  content: 'Growth decelerating to 14% CAGR based on Q4 data.',
  intent: { purpose: 'Update market projection with latest data' },
  confidence: { score: 0.75, reasoning: 'Single source.' },
  relations: [{
    type: 'contradicts',
    target_id: 'mem-001',
    description: 'Original estimate was 23% CAGR; new data suggests 14%'
  }]
})
// → Field automatically creates a Conflict object

The next time the strategist attunes, they receive both findings plus the unresolved conflict. They can then resolve it using one of seven structured strategies - from last_write_wins to confidence_weighted to human_escalation.

What it looks like end to end

Here's a complete Level 0 example, two agents sharing memory in under ten lines:

import { Field } from '@akashikprotocol/core'

const field = new Field()

const researcher = await field.register({ id: 'researcher-01', role: 'researcher' })
const strategist = await field.register({ id: 'strategist-01', role: 'strategist' })

// Researcher records a finding — intent is required
await researcher.record({
  type: 'finding',
  content: 'European SaaS market growing at 23% CAGR',
  intent: { purpose: 'Validate market size for go-to-market strategy' }
})

// Strategist attunes — receives relevant context automatically
const context = await strategist.attune({ max_units: 10 })
// → Returns the finding, ranked by relevance
// → Every result includes WHY it was recorded

That's Level 0. No persistence, no embeddings, no configuration. Just shared memory with intent.

Progressive adoption

You don't have to adopt the full protocol at once. Akashik is designed for progressive adoption; every level adds capability without requiring you to rewrite what already works.

Level	Name	What you get	Effort
0	Starter	REGISTER, RECORD, ATTUNE. In-memory.	An afternoon
1	Core	+ Persistence, logical clocks, conflict detection, polling.	A week
2	Standard	+ Semantic attunement, MERGE, push subscriptions, REPLAY.	Serious build
3	Full	+ Security model, authority hierarchy, coordination extension.	Production-grade

Start at Level 0. It solves the core problem, agents sharing memory with intent tracking, with almost no overhead. Move up when you need to.

What Akashik is not

Not a vector database. Akashik is a protocol, not an implementation. It defines the contract; you choose the storage.
Not a message queue. Agents share structured, intent-bearing context, not raw messages.
Not a replacement for MCP or A2A. Akashik is the memory layer. MCP and A2A remain the tool and communication layers.
Not a framework. It's framework-agnostic and transport-agnostic. Any agent system can adopt it.

Where things stand

The specification (v0.1.0-draft) is live now. It covers:

Nine core operations (REGISTER, DEREGISTER, RECORD, ATTUNE, DETECT, MERGE, SUBSCRIBE, REPLAY, COMPACT)
Four conformance levels with normative requirements
Full data type definitions with JSON Schema reference
Error model with recovery guidance
Transport bindings for Native SDK, MCP Server, and HTTP REST
Security model and authority hierarchy

The Level 0 SDK (@akashikprotocol/core) ships in April — TypeScript, in-memory, the exact code examples above will run.

This is deliberately early

The spec is in draft. The best protocols are shaped by the people who use them.

If you're building multi-agent systems and you've hit the stateless agent wall, I'd genuinely value your perspective:

Read the spec and tell me what's missing
Open an issue with what you'd change
Tell me what you'd build if your agents could share memory

Links:

Website & docs: akashikprotocol.com
GitHub spec: github.com/akashikprotocol/spec
npm: @akashikprotocol/core

The missing layer in the agent stack is memory. Let's build it right.

~ Sahil sahildavid.dev