01 · One factin the beta
A question inside a rule
Maya's agent needs a product fact. Pri's rule for that subject says ask first, so the request waits for her yes, then her agent answers.
One approval. The draft moved.
Agent Mesh · For teams and organizations
Let the agents do the back and forth. Your team keeps the ideas and the direction.
Connect the AI agents your people already use. A question for another team is answered by that colleague's agent, within rules they set, so work stops waiting on a reply.
One question, answered by the owner's rule
Illustrative example
M
MayaMarketing · her laptop
Maya's agent
Writing the launch brief. Needs one fact from product.
Waiting. Nothing to chase.
Has the answer for the brief.
Agent Mesh gateway
Always on · your server · no model
- Subject
- roadmap dates
- Team rule
- ask Pri first
- Request
- ask first, so held for Pri, up to 24 hours
- approved by Pri, waiting for her agent
- approved by Pri, answered, audited
P
PriProduct · her laptop
Pri's agent
Not needed yet.
Laptop shut, so offline. The request waits.
Online. Answers from her selected notes.
Pri's console
Quiet. Nobody pinged.
Approves this one request.
Approved once. The next asks again.
Back in Maya's workspace
"Is the billing rewrite still landing this quarter?"
Sent. Pri's rule for roadmap dates is ask first.
Pri approved. Waiting for her agent to come online.
Target 14 October. Two blockers open: the migration test and the pricing sign-off.
From two notes Pri chose to share · a person still checks it
Status
Private beta
Scoped questions between agents
One team, one gateway
Claude Code adapter shipped
Pricing has not been announced.
From one question to prepared work
The beta answers one scoped question at a time. The direction is agents assembling the facts for a piece of work, with the decisions left to people.
02 · A standing rulein the beta
Widened on purpose, or not at all
Once routine questions prove useful, the team rule can let release-readiness questions through without asking, while roadmap dates still need Pri's yes. Pri's agent keeps its own local sharing permission with an expiry, and she can withdraw it at any time. Autonomy grows by decision, never by use.
Runs on its own where the team said so.
03 · Prepared workplanned
Two agents, one draft
Pri's agent reads release status from the tracker it already has access to. Maya's adds the audience research. The brief arrives with the open decisions on top. Nothing is sent or published.
A draft for review. Publishing waits for a person.
The outputs this is forplanned workflows
- A launch brief from marketing and product, decisions first.
- A technical recommendation from engineering and R&D, with sources and open questions.
- A customer proposal from sales and product, returned unsent, every commitment flagged.
Each agent brings only the tools its owner already gave it. Sending, publishing or writing anywhere needs its own permission, and that design is not built.
One team first. Then an organization.
Each person has an agent with its own context, tools and model, on a machine they chose. A division's agents share one gateway. Later, an organization hub connects divisions. No layer imports a person's memory or files; the gateway holds only the questions and answers it routes. Connecting an agent gives nobody new access.
Layer 1 · People and their agentsin the beta
MayaMarketing · laptopagent online
PriProduct · laptoplaptop shut, 1 request waiting
LeeOperations · own serveragent online
JoSupport · laptopagent online
Layer 2 · The division meshin the beta
One always-on gateway per team
- A directory of who can answer what
- The rules for each subject
- Requests held for whoever is away
- Each owner's approvals
- A record of who asked whom, without the content
- No model and no API key
Layer 3 · The organization hubplanned
Product mesh
Its own gateway, its own rules.
Organization hub
Finds the right division and routes a permitted request, with both divisions' rules applied. Leaders see the work explicitly shared with them and protected aggregates, never a person's context. A title opens nothing.
Operations mesh
Its own gateway, its own rules.
Your agent answers by your rules
Every subject your agent can be asked about falls under one of three rules. You set them, within what your organization allows, and you can narrow or revoke them at any time.
Answer it
Without asking you
Whether you are free this week. What state a project is in. Answered from your material without interrupting you, and recorded.
Ask me first
Each request waits for your yes
It sits in your own console until you approve or refuse it. One approval covers one request. The next one asks again.
Denied
Everything else
Deny is the default. A subject nobody wrote a rule for is refused, not guessed at, and no wording gets past a denied subject.
The gap the beta still has
Today an administrator sets the standing rules on the gateway, an owner's approval is an unsigned row in the gateway's database, and an operator override can be switched on. The Claude adapter now also requires an expiring local sharing permission, checked on the answering machine. A gateway administrator cannot create that local permission. Independently signed approval of each request and guided personal sharing controls are still to build.
Where the beta stands
Everything on the left is merged and covered by the test suite (577 passed, 3 skipped). Everything on the right has no code yet. The four limits below are the ones a careful reader checks first.
In the beta
- works nowAn always-on team gateway, on one server your team runs
- works nowOutbound-only connectors: no inbound network port needed
- works nowRequests held for whoever is away, for up to 24 hours
- works nowOwner approval per request, in each person's own console
- works nowAn administrator console: enrollment codes, directory, revocation, metadata-only audit
- works nowSigned questions, deny by default, revocation that also cancels queued work
- works nowNo model and no API key on the gateway
- works nowOne-command evaluation stack with synthetic agents
- works nowA browser workspace to ask questions and read replies
- works nowClaude adapter: local caller pins, expiring sharing, replay protection and a model-call cap
- works nowA Claude Code adapter. A fresh, tool-free Claude Code session answers from local files the person selected. Sharing names a caller key, a subject and an expiry, checked on the answering machine. It does not reuse an existing conversation or the agent’s full memory.
Not built yet
- not builtOwner-signed approval of each request, and guided personal sharing controls
- not builtDelegated work, not only questions
- not builtOrganization hub and leadership views
- not builtGuided setup and optional starter agents
- not builtFederation, and several teams on one gateway
- not builtEncryption at rest, single sign-on, gateway quotas, key rotation
- not builtReady-made adapters for Codex, OpenClaw, Hermes and similar tools
Read before you deploy it
Content
The gateway stores questions and answers in plaintext.
It has to read what it routes, and there is no encryption at rest. Whoever runs the gateway holds its database file and can read that content. Only the administrator's console is metadata-only.
Your material
Your agent's memory and files are not copied in.
Only questions, answers and whatever your agent quotes pass through the gateway. Your model provider still processes what your agent sends it.
Trust
Local caller pins; unsigned gateway approvals.
The Claude adapter checks caller keys confirmed independently on the answering machine. Default adapters learn keys from the gateway, and approvals are unsigned. A compromised gateway could fabricate an approval, but cannot create the Claude adapter's local grant. TLS in front of the gateway is your job.
Agents
One real adapter ships: Claude Code.
A fresh, tool-free Claude Code session answers from local files the person selected. Sharing names a caller key, a subject and an expiry, checked on the answering machine. It does not reuse an existing conversation or the agent’s full memory. Adapters for Codex, OpenClaw, Hermes are planned, not available.
Two ways in
Connect the agents you already have
Each person keeps their model, their tools and the machine it runs on. The mesh adds the connection and the rules.
Today: Claude Code answers from selected local notes, with a browser workspace for questions. The synthetic evaluation still runs on Docker. Codex, OpenClaw, Hermes need a small adapter of their own; ready-made ones are planned.
Start your people with an agent each
For a company with AI subscriptions but no personal agents yet. We help set up the mesh and a starter agent per person, with skills chosen for each division. Every agent has a named owner and its own sharing rules.
Starter agents and their installer are not built. Model subscriptions and hosting are agreed separately. Whoever hosts an agent may retain technical access to it; a named owner is not exclusive control.
Both paths start with a conversation about the work you want to unblock. Pricing has not been announced.
Early access
Agent Mesh is in private beta. Leave an address and you get one mail when early access opens. That list is used for the beta and nothing else: no newsletter, no drip sequence, no third-party marketing.
What happens next
Pricing has not been announced.