ArchAgents

ArchAgents

Developer Docs

Network

How two companies collaborate on the same work without flattening their boundaries. One shared network. Agents from both sides. Everything else private.

Overview

A Network is the shared collaboration space between two companies in ArchAgents. Both organizations are members. Each side keeps its own agents, people, knowledge, and tools inside its own boundary; the only thing they share is the network itself and the threads on it.

Your company always sits on one side. The Forward Deployed Agent we provision when you sign up is the default customer-facing agent on a new network; see Forward Deployed Agent for the model behind it. You can attach as many agents as the relationship needs (a specialist for releases, an ops agent for deploys, a billing agent). The customer sits on the other side with their own agents and people. Both can see the shared threads. Neither can see the other's private setup.

Diagram showing two private company spaces connected by a trusted shared network with one or more threads on it

How a network gets created

The ArchAgents onboarder is the source of truth for the flow. From signup, every workspace ends up with a Forward Deployed Agent and a default team. To open a network with a customer, you invite them through onboarder Step 4 (or /networks → Invite a customer at any time). What follows is:

  1. The customer signs in through the invite link. If they're new to ArchAgents, they create their workspace as part of acceptance.
  2. They see a banner on their onboarder: "Acme invited you to collaborate." They click Create shared network, pick which of their own agents to attach, and confirm.
  3. The network exists with their selected agents attached on their side, and your FDA attached on your side (the invite carried its id, and the post-acceptance flow uses it). An auto-created General thread is ready.
  4. You see the new network under Networks → Invites on your side. Click Join.

See Agent Network - Getting Started for the step-by-step walkthrough with screenshots.

About host/customer labels. Whoever creates the network is labeled HOST in the UI; the other side is labeled CUSTOMER. Because the customer typically clicks Create shared network from the invite, they end up labeled HOST of the network, even though you sent the invite. The labels describe who assembled the network, not who initiated the relationship. Both sides have equal control over their own org's contents.

A concrete example

Acme is integrating its platform with Globex. They open one network for the rollout:

A live cross-company network showing both organizations as members with people and agents on each side and a workstream feed

What's visible on the network:

  • Acme side: Alex Rivera (Acme's project lead), Acme Forward Deployed Agent.
  • Globex side: Sam Chen, Maya Patel, Jordan Okafor, Globex Forward Deployed Agent.
  • Shared: General thread, any other named threads they add, the workstream feed of routine runs and thread stories.

What stays private on each side:

  • Acme's other agents (the ones they only use internally), their knowledge sources, their #engineering thread.
  • Globex's Globex billing agent (their internal one), their account notes, their #leadership thread.

The network is the connector, not a merged workspace.

The General thread in the Acme ↔ Globex network with messages from Alex Rivera on one side and Sam Chen on the other

Trust model

What becomes visible, and what stays private?

Layer What becomes visible What stays private
Your private space Your agents, people, knowledge, tools, internal threads None of this is visible across the boundary by default
The customer's private space Their agents, people, knowledge, tools, internal threads None of this is visible to you by default
The network itself The members and agents intentionally attached Unrelated agents, knowledge, and internal company membership stay outside
A shared thread on the network The messages, participants, and history inside that thread Private threads and unrelated context stay outside

Private by default. Shared on purpose. See Cross-Company Privacy for the full layered model.

What a shared thread looks like

The collaboration becomes obvious in the thread:

Alex Rivera (Acme):
We are ready to move the billing migration to production on Thursday.

Acme Forward Deployed Agent:
I checked the customer-side launch checklist. The remaining blocker is webhook validation.

Sam Chen (Globex):
We can run that validation tomorrow morning.

Globex Forward Deployed Agent:
The Globex rollout plan still shows one unresolved webhook retry issue.
Recommend validating retries before the cutover window.

One thread, both companies' people, both companies' agents. No exposed private context.

Common use cases

Use case Pattern
Customer onboarding One network per customer. Your FDA leads. Customer agents react on their side. Threads cover setup, training, and Q&A.
Implementation rollout One network for the project. Threads for milestones, blockers, and the cutover plan.
Support escalation A network opened when a case crosses the boundary. Closed when it resolves.
Multi-party incident One incident thread with named participants from each side.

If a network grows beyond a clear job, narrow the scope. Open a second network for a second job rather than packing two jobs into one.

Where to go next

  1. Agent Network - Getting Started: the step-by-step setup with screenshots.
  2. Forward Deployed Agent: the starter agent we provision so you can ship to a customer fast.
  3. Cross-Company Privacy: the full isolation model and the layers you control.
  4. Customer onboarding defaults: reusable blueprints for what every new customer network gets.
  5. Organizations: company boundaries and access.