Imagine a software team with ten people. Each person already uses an agent. Across a normal week, those ten agents may open more than a hundred coding, research, testing, and review sessions.
The obvious next step is to connect them. A product agent should be able to ask the authentication agent for an interface contract, route an implementation task to a coding agent, request an independent security review, and return one verified result to the team.
But simply allowing every session to message every other session does not create a team. It creates an ungoverned network: duplicated work, uncontrolled context sharing, unclear authority, cascading errors, and no reliable way to recover.
The product we want is different:
Turn independently owned agents into a permissioned, recoverable, evaluable, and learnable collaboration network.
That is the systems problem behind SharedOS, PACT, and Aicoo.
Keep Your Agents. Connect Them Through a Runtime.
We do not think every company should replace its existing agents with one centralized super-agent. Teams should keep the agents they already trust: coding agents, research agents, internal assistants, or models they host themselves.
In the architecture we are building, each durable agent connects through an Agent Gateway. The gateway represents an accountable owner: one person, team, or service. It carries identity, permissions, relationships, budgets, and durable memory.
Short-lived work sessions are different. They are workers, not new durable identities. A gateway can create many workers for implementation, testing, browsing, or verification. Each worker receives a bounded task and runs inside an isolated sandbox. When the task finishes, the sandbox disappears; its approved artifacts and provenance remain in SharedOS.
This distinction matters. Ten developers may have ten durable gateways and more than a hundred active or historical workers. We should govern the ten accountable identities without pretending that every temporary session is a new employee.
| Layer | Responsibility |
|---|---|
| Existing agents | Reasoning, domain expertise, and tool use |
| Agent Gateways | Durable identity, ownership, policy, and capability discovery |
| SharedOS | Relationship-scoped memory, permissions, artifacts, audit, and recovery |
| Coordination runtime | Routing, delegation, concurrency, verification, escalation, and retry |
| Isolated workers | Bounded execution in disposable microVMs |
| PACT-Bench | Replayable evaluation of utility, security, and network failure modes |
| Aicoo | The production field network where real teams use the system |
The microVM is therefore not the product and not a permanent machine assigned to each user. It is an execution boundary created for an active task. Cost follows active work, not the number of registered people.
A Concrete Coding Example
Suppose a product lead asks:
Add relationship-aware sharing to project notes, including API changes, migration safety, tests, and a security review.
In a conventional agent workflow, one coding agent receives the entire request and a large repository context. It may implement the feature, but the human still has to find the right owners, transfer context, inspect the migration, request review, and reconcile the outputs.
In a governed network, the runtime can execute a different plan:
- The product lead's gateway turns the request into an explicit delegation contract: scope, success criteria, deadline, budget, and actions that require approval.
- The runtime routes the permission question to the identity owner's gateway and sends only the relevant schema and interface, not the whole workspace.
- Separate implementation, test, and security workers run in isolated microVMs. They share artifacts through SharedOS rather than inheriting one unrestricted context window.
- A verifier checks the patch against the contract, tests, and security policy. Failed evidence triggers a bounded retry instead of an unobserved conversational loop.
- The runtime records who requested each action, which context crossed each boundary, what tools ran, which model produced each artifact, and why the final result passed.
- A human approves the consequential step: merging or deploying the change.
The result is not merely parallel execution. It is dynamic routing under ownership constraints.
Where New Capability Can Emerge
A network has degrees of freedom that a single agent does not:
- Topology: which agent talks to which other agent;
- Decomposition: how a task is split and where dependencies are placed;
- Branching: how many workers run in parallel;
- Context bandwidth: what each worker sees and what it may forward;
- Specialization: which agent performs, critiques, or verifies each step;
- Trust: which evidence is sufficient before authority expands;
- Recovery: when to retry, reroute, roll back, or ask a human;
- Memory: which outcomes become durable knowledge and for whom.
Those choices can create capabilities that no individual agent has: cross-team knowledge routing, parallel investigation, peer verification, and graceful recovery from a weak worker.
They can also create new failures. A plausible but wrong artifact can propagate through the graph. Permissions can accumulate across a delegation chain. Two agents can reinforce the same mistake. More messages can consume the entire gain from parallelism. A fact protected in one direct exchange can leak through an intermediary.
We are not trying to remove emergence from the system. We are trying to make it governable: observable while it happens, bounded by policy, recoverable after failure, and measurable across repeated runs.
What PACT Has Already Taught Us
We built PACT-Bench because an agent network cannot be governed by intuition alone. PACT runs on the SharedOS execution path with seeded worlds, real tools, model provenance, replayable policies, and database-diff ground truth for PACT-PAIR actions.
PACT-PAIR measures one requester–responder boundary. PACT-NET extends the same problem to a 25-agent organizational graph, where delegation and transitive information flow become visible.
Three findings shape the runtime we are building:
| Evaluation | Tested result | Runtime lesson |
|---|---|---|
| PACT-PAIR across six requester configurations with a fixed responder | The category-specific policy reduces disclosure by 69–91 percentage points; utility falls by 1–29 points | The security direction repeats, but its cost depends on the requester configuration |
| Length-matched policy control | Generic / length-matched generic / full category policy disclosure is 81.5 / 80.0 / 14.0% on Files and 63.0 / 62.0 / 8.0% on States | Raw length and redundant generic elaboration do not explain the large P2 gain; content and rules remain bundled |
| PACT-NET | Static policy raises composite safety from 26.6 to 71.5%, while transitive leakage falls only from 96.3 to 77.7% | A policy that helps one boundary does not solve network propagation |
These are trade-offs across tested discrete operating points. We do not infer a continuous frontier from them. In these evaluations, disclosure means an unauthorized revelation on a protected request; legitimate sharing is measured as utility.
The larger lesson is that prompts are one control layer, not the runtime. Production coordination also needs context reachability, capability-scoped tools, relationship-aware permissions, verification, escalation, and recovery. Each layer answers a different failure mode.
The Research Question: Scaling Laws for Agentic Communication
Model scaling asks how capability changes with parameters, data, and compute. Agent-network scaling adds a different set of variables:
- network size and topology;
- delegation depth and branching factor;
- communication and context budgets;
- verifier placement;
- trust and escalation thresholds;
- memory persistence;
- task dependency structure.
The output cannot be one accuracy score. We need to measure task success, latency, cost, unauthorized disclosure, action safety, recovery rate, human intervention, and the value of durable memory together.
We are not claiming that a universal scaling law has already been discovered. We are building the runtime and evaluation infrastructure required to search for one. The question is not simply whether more agents help. It is:
Under which coordination policy does adding another agent improve verified capability faster than it increases cost and risk?
That question is experimentally answerable only when the runtime records the complete path from task to outcome.
From Execution Traces to a Learning Loop
Every governed run can produce a provenance-linked trace:
task + ownership graph + policy + mounted context
-> routing and delegation decisions
-> tool calls and intermediate artifacts
-> verification, escalation, and recovery
-> utility, security, latency, and cost outcomes
Over time, those traces can improve the coordination policy itself. The system can learn which agent to route to, how much context to reveal, where a verifier is worth its cost, when parallelism helps, and which failures should trigger a human escalation.
This is the compounding technical asset: not a collection of prompts, but a runtime, a benchmark, and a field network producing compatible evidence. SharedOS provides the durable execution substrate. PACT provides controlled measurement. Aicoo supplies real coordination problems and the feedback needed to keep the research honest.
The Product Entry Point and the Deeper System
The product entry point should be understandable in two weeks:
Connect your existing agent. Let it route work securely to other agents through Aicoo.
The system underneath should remain difficult to reproduce after two years:
- relationship-aware identity and memory;
- dynamic, policy-constrained routing;
- isolated and recoverable execution;
- end-to-end provenance;
- benchmarks for pairwise and network behavior;
- coordination policies trained from verified outcomes.
That is how ten independently owned agents become more than ten chat windows. They become a collaboration network whose new capabilities can emerge without leaving ownership, security, and accountability behind.
We are building the runtime for that network—and the instruments to determine when it deserves to be trusted.
Explore the PACT benchmark, read the SharedOS and Aicoo documentation, or follow our ongoing work on the research page.