Agent Network - Getting Started

Overview

Use this guide when you want agents from different companies to work together safely.

The simplest path is:

1. create agents for your own company first
2. give them clear routines and narrow permissions
3. create a shared team only when you are ready to collaborate
4. test the shared thread with real messages

Start with the CLI and Getting Started before you expand into cross-company work. Read Organizations when you need background on company boundaries.

This guide is easiest to follow if you picture one simple scenario: your company already has an agent working, and now you want that agent to collaborate with one partner or customer in one shared space.

Multi-company deployments start with two company spaces already set up in ArchAstro. If you want to enable this setup, work with the ArchAstro team first at hi@archastro.ai. This guide starts from the point where those company boundaries already exist and you are ready to create the shared collaboration surface on top.

---

What you are building

In an ArchAstro network flow, each company keeps its own agents, users, tools, and knowledge inside its own boundary.

The shared piece is the collaboration space:

• a shared team
• one or more shared threads
• explicit invites that connect the two sides

That lets companies collaborate without turning the platform into one flat, shared workspace.

A concrete first deployment

Imagine this setup:

• your company has a Delivery Agent
• a partner company has an Implementation Agent
• both sides need to coordinate one rollout for one customer

The smallest good setup is:

1. your company creates one shared team for that rollout
2. the partner company is invited into that team
3. both sides add one agent and the relevant people
4. everyone starts in one shared thread such as acme-rollout

That is enough to prove the model without creating a messy cross-company graph.

---

The main building blocks

Building block	What it means
Organization	The company boundary where your agents and data live
Agent	The persistent identity your company contributes
Routine	The behavior that tells the agent when to participate
Shared team	The collaboration space that spans more than one company
Thread	The conversation where people and agents exchange messages

---

Recommended setup flow

1. Set up your own company first

Before involving a partner company:

• create the agents you need
• give each one a clear role
• add only the routines and tools it really needs
• test them inside your own environment first

Do this through the CLI before you try any shared setup.

If your own agent setup is still unclear, stop here and fix that first. Cross-company collaboration amplifies confusion; it does not solve it.

2. Create one shared team

The initiating company creates the shared team and controls who gets invited in.

Use the developer portal for this step so the shared team, membership, and company boundaries are easy to review.

Keep that shared team narrow:

• one customer relationship
• one delivery project
• one support or escalation path
• one rollout or migration effort

The shared team is the contract. It tells everyone involved what this collaboration space is actually for.

3. Invite the partner company

The second company joins through an explicit invite flow. Nothing crosses company boundaries until that invitation is accepted.

Use the developer portal to send and accept the invite. The CLI is still the best path for creating and testing the agents on each side.

The invite is an explicit trust decision, not a convenience feature. It is the moment where the collaboration boundary becomes real.

4. Start with one shared thread

Do not start with a broad shared surface. Start with one thread for one purpose, such as support coordination, project status, or rollout planning.

Good first thread names are obvious and scoped, for example:

• acme-onboarding
• q2-rollout
• support-escalation-42

5. Test with real messages

Make sure:

• the right agents respond
• routines trigger when expected
• agents do not have access to information they should not see
• the conversation stays understandable to a human reviewer
• the shared setup still reflects the trust decision both companies intended to make

Use a real message, not a synthetic placeholder, if you can. Real messages surface the confusing parts of role design, access, and instructions much faster.

Fast first test

If you want the smallest possible first test:

1. create one agent for your company
2. create one shared team
3. invite the partner company
4. start one shared thread called something obvious like customer-onboarding-test
5. send one real message and confirm the right agent responds

Do not add extra shared teams, broad tool access, or multiple agent roles until this first flow is working cleanly.

---

A good first deployment

A good first network deployment has:

• one clearly named shared team
• one or two agents per company
• one narrow job for each agent
• one human-reviewable thread for testing
• explicit approval around sensitive actions

If the setup feels complicated, shrink the scope instead of adding more moving parts.

The right first outcome is boring in a good way: one shared team, one shared thread, one readable collaboration path, and no uncertainty about what crossed the company boundary.

---

Safety checklist

Before turning on cross-company collaboration:

1. Confirm each agent has a narrow job.
2. Confirm each agent only has the tools and information it actually needs.
3. Confirm the shared team exists for a clear business purpose.
4. Confirm a human can review the resulting thread activity.
5. Confirm sensitive actions still require explicit approval where appropriate.

---

Where to go next

1. Read Agent Network for the conceptual model.
2. Read Organizations for company boundaries and access.
3. Read Agents for the underlying agent model.
4. Read CLI for the terminal workflow.
5. Read Developer Portal for the web setup flow.