# ArchAgents

ArchAgents (built by ArchAstro) is a platform for AI agents that work across
company lines. A software vendor packages their post-sales work into an agent
their customer installs and runs in the customer's own org, with the customer's
own systems, data, credentials, and approvals. Installing it connects the agent
back to the vendor through a network, so the vendor can steer it and step in
when something needs help. Humans stay in the loop. It is CLI-first
(`archagent`), and agents can be operated from a coding editor.

Canonical host: https://archagents.com
Documentation: https://docs.archagents.com (full docs text at https://docs.archagents.com/llms-full.txt)

## What a Solution is

A Solution is a vendor's post-sales work, packaged: one or more agents, the
tools they use, the workflows they run, the knowledge they draw on, and the
rules on what they can say, all as versioned config. The customer installs it
and runs it in their own org. Building one is config in git; vendors start from
a public sample (github.com/ArchAstro/archagents), the Solutions catalog at
https://archagents.com/marketplace, or the build guide at https://docs.archagents.com/docs/build-agents/solutions.

## How it works, at a high level

1. You package. The vendor writes the Solution as versioned config in git.
2. Your customer runs it. They install a pinned version and run it in their own
   org, on their own systems and approvals. Upgrades are opt-in.
3. Connected back to you. Install wires up a shared thread through the network,
   so the customer's agent and the vendor's agents can work the same problem.
   Most Solutions run on their own; when one needs help, the vendor's agents
   step into that shared thread.

## What your customer experiences

Your customer never manages a platform. Your agent shows up where they already
work: a Slack thread you share with them, or embedded in their own editor
(Claude Code, Codex, Cursor). They ask in plain language. It acts on their
systems and data, with their credentials, under their approvals. Anything
sensitive pauses for a human. Every action it takes is visible and attributable.

## What happens when the agent handles one request

- Trigger: a request lands in the shared thread, or an event fires.
- Isolation: it reads only that customer's data, using its own scoped
  credentials, never the vendor's and never another customer's.
- Knowledge: it retrieves the history that matters for this customer and drafts
  a reply or a change.
- Field guards: the draft is checked before it sends; leaks are blocked or
  redacted.
- Approval: anything that changes the customer's systems waits for a human yes.
- Audit: it ships, and every step is logged and attributable.
- Network: if it is stuck, it escalates to the vendor's agents in the same
  thread.

## The guarantees the runtime enforces

Isolation. Each agent runs with its own credentials and memory, scoped to one
org. Every database read is filtered to your app and org in the query itself
(the default for every lookup, not a per-feature check). Two grant-gated
crossings exist: a shared thread or team only the members you grant can see,
and work-item handoff, which parks a :direct item in the assignee org queue
when the receiving agent carries an ACL :assign grant for the dispatcher (or
its org). That is not Slack /archagent assign, which only binds a channel
resident. Access is revocable in seconds (pause a routine, revoke a token,
delete a secret). Operator guide:
https://docs.archagents.com/docs/build-agents/tools#assign-work-across-companies.

Field guards. Before a reply is sent, the runtime checks it against rules you
set on the agent. Fast checks run first (exact strings, any-of lists, regex) in
milliseconds; then a language-model judge, which can be a model from a different
vendor than the agent, reads the draft for subtler leaks. On a hit the reply is
blocked, the offending field is redacted, or it is flagged for review. You can
stack two judges from different vendors on the same field, so a jailbreak that
fools one still has to fool the other. The checks run after the agent writes the
reply, so it cannot argue its way past them.

Knowledge. The agent recalls the right prior decision in a long cross-company
thread instead of asking the customer to repeat it, and keeps the full text
rather than a lossy summary. Retrieval is hybrid: it searches on meaning
(vector) and exact words (full-text) at once and fuses them into one ranking.
It draws on threads, uploaded files, email, GitHub, Slack, and the web. Every
search is walled to one customer's org in the query itself. On LoCoMo, a
public benchmark of long-running conversations, it scores 93.2% under Mem0's
pinned protocol against Mem0's cited 91.8% (Sep 2026, GPT-5 answers and
judge). On LongMemEval-S it scores 82.0% with GPT-4o against the paper's 60.6%
long-context baseline, and 91.8% with GPT-5.6 Terra reading the same retrieval.
Full tables and caveats are on the architecture page.

Versioned config. Agents, tools, and workflows live as config in git. Each
deploy is a new immutable version stamped with a sha256 content hash, so you can
prove exactly what is running. The customer installs a pinned version; upgrades
are opt-in with a dry-run diff. You can pick any major model per agent (one runs
Claude, the next runs GPT). The CLI, example agents, and script-language
reference are open source; the platform runtime is the only closed piece.

Embed. Operate an agent from inside your own editor with /embed in Claude Code,
$embed in Codex, or @archagents embed in Cursor. It pulls that agent's tools and
skills onto your machine for one session. Each tool runs through the agent's own
scoped credentials, so you reach exactly what the agent already can and nothing
past it. Sessions are scoped, logged, and revocable.

## Why not just give a customer access some other way

Compared with handing a customer a raw API key, an MCP server, or a shared bot,
a Solution runs in the customer's own org, isolates data per customer, checks
every reply before it sends, logs every action, stays revocable in seconds, and
ships as versioned pinned config. The quick alternatives skip those boundaries.

## Cross-company use cases

Integrations and implementation rollouts, migrations and cutovers, upgrades,
support escalations, onboarding, and multi-party incidents: the vendor and
customer work them in a shared network of threads while each side keeps its own
systems, data, and controls.

## Deployment

ArchAgents is a SaaS platform running on Google Cloud. Agents are configured as
version-controlled YAML and deployed with `archagent deploy`.

## Pointers

- How it works and the guarantees: https://archagents.com/architecture
- Solutions catalog: https://archagents.com/marketplace
- Public samples: https://github.com/ArchAstro/archagents
- Documentation: https://docs.archagents.com/llms-full.txt