The platform

The agent runtime that runs all our products

Customer-facing agents touch different channels, credentials, data, and approval chains. Without one enforced runtime, every new customer and workflow becomes another security boundary your engineers have to build and operate themselves.

ArchAgents is the runtime beneath all three products. It isolates credentials, gates actions, checks every output, pins versions, and logs each step. A shared workspace lets your team step in and help, and everything stays between you and your customer.

Our products

Agent Solutionsin your customer’s environment Agent Slack Botin a cross-company channel you share Agent RoomsBetain your own team’s room

The ArchAgents runtime

Cross-company workspacesInstalls into their coding agentAn agent per customerAgents with their own computersCross-vendor output judgingFail-closed privacy in the data layerEvals on every agent

Everything between you and your customer happens in the shared workspace created at install.

Book a demo Read the docs

One system, three work surfaces

Connect customer work, engineering work, and action

ArchAgents runs across the places where software companies build with and support their customers. Because every product runs on the same platform, customer signals can reach engineering and engineering work can become action inside each customer’s organization.

Customer work
Agent Slack Bot
Captures questions, problems, decisions, and requests from the channels your team shares with each customer.
Engineering work
Agent Rooms
Connects those signals to what your engineers and their coding agents are building, deciding, and shipping.
Action
Agent Solutions
Performs repeatable integrations, migrations, upgrades, and fixes inside the customer’s organization, under their credentials and approvals.

Each product works independently. Together, they create a continuous path from customer signal to engineering context to action, while each company keeps control of its own data, systems, and permissions.

How it works

How a Solution runs inside your customer’s boundary

The platform gives every Solution agent a scoped identity, isolated knowledge and credentials, approval gates, output rules, versioning, and a complete audit trail. The walk-through below follows one from install to escalation, inside your customer’s environment.

01 · You package

Solutionv1.4

agenttoolsknowledgepolicy

versioned config, in git

02 · Your customer runs it

Installedpinned v1.4

their datatheir credsapprovalsaudit

runs on its own, in their org

03 · Connected back to you

their agentyour agent

When it needs help, your team steps in

a shared thread, wired up on install · every reply checked before it ships

The install also connects you and your customer through a shared workspace. Solutions can work on their own in your customer’s org, and ask your agents or your engineers for help when they need it.

Building one is straightforward: a Solution is config in git. Start from a sample on GitHub, browse the Solutions catalog, or follow the build guide.

What your customer sees

They just talk to your agent, from where they already work

Your customer never manages a platform. They ask in plain language, in the Slack thread you share or from their own harness, and the agent works in their local harness.

In a Slack thread you share with them, or embedded in their own editor: Claude Code, Codex, or Cursor.
It acts on their systems and data, with their credentials, under their approvals.
Sensitive actions pause for a human before anything changes.
Every step it takes is visible and attributable, so they always know what it did.

The end-to-end flow in the docs

Follow a request

What happens when the agent gets to work

One request, start to finish.

01Trigger
A request lands in the shared thread, or an event fires.
02Isolation
It reads only that customer’s data, with its own credentials.
03Knowledge
It pulls the history that matters and drafts a reply.
04Field guards
The draft is checked before it sends. Leaks get blocked or redacted.
05Approval
Anything that changes their systems waits for a human yes.
06Audit
It ships, and every step is logged and attributable.
07Network
If it needs a human, it brings your team into the shared workspace created at install.

Isolation

Agents can be scoped and authorized to only what they need

Your customer runs the agent in their own org, on their own systems, behind their own approvals. Two companies work together without either one handing over the keys.

Each agent runs with its own credentials and memory, scoped to one org, so one customer’s data stays isolated from another’s.
Every read is filtered to your org in the query itself. That is the default for every lookup, not a check someone remembers to add per feature.
Anything that crosses between two companies goes through a thread or team you grant, and nothing else.
Every action is logged, so your security team can see what was shared, by which agent, and when.
Access can be pulled at any time, and sensitive actions wait for a person to approve them. You can test against a sandbox before anything touches production.

Cross-company privacy in the docs

Field guards

Every reply runs through your rules before it crosses to the other company

You write the rules on the agent, and every draft reply is checked against them before it sends. Fast checks run first: exact strings, any-of lists, and regex, all in milliseconds. Then a language-model judge reads the draft for the leaks a pattern would miss.

On a hit, the reply is blocked, the offending field is redacted, or it’s flagged for review. Your rules decide which.
Put judges from two different model vendors on the same field. A jailbreak that fools one still has to fool the other.
The checks run after the agent writes the reply, so it can’t argue its way past them. A blocked reply is retried, then held back. It never reaches the thread.
The rules live in the agent’s config, versioned and reviewable like the rest of it.

Field guards in the docs

Knowledge

Agents remember each customer, across long threads

In a long cross-company thread, the agent pulls up the decision you already made instead of asking your customer to repeat it. It keeps the full text of what it learns, not a summary that drops the detail you need three weeks later.

Search runs two ways at once, on meaning and on exact words, and fuses them into one ranking.
It draws on threads, uploaded files, email, GitHub, Slack, and the web, each source indexed as raw text.
Every search is walled to one customer’s org in the query itself. One customer’s agent can’t reach another’s.
The agent keeps per-customer working memory you can list and audit from the CLI.
Benchmarked on public academic datasets against strong baselines, with sourced results.

The knowledge system in the docs

Knowledge benchmarks

Measured against published baselines

This is why the agent answers from your real history instead of a stale summary. Raw-text hybrid retrieval, measured on public academic datasets with GPT-4o answering.

ConvoMem · single-conversation recall (2,843 questions)

Overall accuracy across 6 categories. Xu et al. 2025, arXiv:2511.10523.

Configuration	Accuracy	Source
LLM extraction + hybrid RAG	83.6%	ArchAgents baseline
LLM extraction + filesystem search	86.0%	ArchAgents baseline
ArchAgents + GPT-4o	94.8%	ArchAgents, Apr 2026

99.6% on assistant-stated facts vs 74% for LLM extraction methods. We index raw text rather than summaries.

Embed

Your customers can operate agents right from any harness

Start an agent inside your 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 still 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, and the company that owns the agent decides who can run it.

Claude CodeCodexCursorRovo Dev

Embedding agents in the docs

The primitives

The best of build and buy

Use our primitives to build custom Solutions that just work. You get the fit of building it yourself, without owning the platform underneath it.

Stop doing it one account at a time

Package the work once, run it everywhere. One versioned Solution carries the agents, tools, workflows, knowledge, and rules. Every customer installs the same thing.
It fits each customer without a fork. The same Solution runs against their systems, their credentials, and their approvals, however bespoke their setup is.
Your engineers stop being the integration. They step in when the agent needs a human, not on every account, every time.
Your brand, not ours. Your name, logo, colors, and support address. Your customer never has to know we exist.

Get through their security review

You never ask for access to their systems. The agent runs on their side under their credentials. The question that stalls deals never comes up.
Their security team can verify it, not trust it. Isolation is enforced in the database layer, so one customer’s data cannot reach another even by mistake.
Nothing crosses that they did not approve. Sensitive actions wait for a human on their side, and every reply is checked before it leaves.
Two model vendors check the sensitive fields. A jailbreak that fools one still has to fool the other.

Cover work an API cannot

Your work lands in their coding agent. Your skills and tools install into their Claude Code, Codex, or Cursor, so the work happens where their engineers are.
Agents get a real machine. A virtual computer per job means browser and desktop work, not only what an API exposes.
It remembers this customer. Each agent keeps that account’s own history, so nobody re-explains the environment every time.
It runs without being asked. Work fires on a schedule or on a trigger, so upgrades and checks do not wait for a person to remember.

Trust it in front of customers

Find out before your customer does. Eval suites grade your agents on real cases, so a regression shows up in a test run instead of in an account.
Rehearse against a real shape safely. A sandboxed agent is refused promotion at the data layer, so a test can never touch a live customer.
Every action is attributable. Your security team and theirs can see what was done, by which agent, when.
You watch the whole fleet. Progress, escalations, and stalls across every account in one place.

The alternatives

Why not just hand your customer access some other way?

You can build any one of these yourself on an API key, an MCP server, or a single support bot. The challenge is that every customer of yours has bespoke conditions and environments that docs and scripts cannot handle on their own.

	An API key	An MCP server	One global support bot	The ArchAgents platform
Runs in your customer’s own org	–	partial	–	✓
Data isolated per customer	partial	partial	–	✓
Access revocable in seconds	✓	✓	✓	✓
Every action logged and attributable	partial	partial	partial	✓
Versioned, with upgrades opt-in per customer	partial	partial	–	✓
Every reply checked before it crosses to them	–	–	partial	✓
Your engineers can join the same job	–	–	–	✓

A check means it comes with the platform. Partial means the piece exists but you assemble and operate it per customer. A dash means it is on you to build from scratch.

Check our work

Don’t take our word for it. Ask your own agent.

You already work with a coding agent. Point it at this page and our docs and have it pull the answer for your role, whether you sit in security, lead the integration, or are the engineer who will wire it up. We publish an llms.txt and keep the docs clean, so your agent gets the plain facts.

Machine-readable: archagents.com/llms.txt · docs.archagents.com/llms.txt

Paste into your agent

Read https://archagents.com/llms-full.txt and https://docs.archagents.com/llms-full.txt, then give me an overview of ArchAgents: what it does, how a vendor packages their work into an agent their customer runs, and how it helps two companies handle cross-company work like integrations, migrations, and support together.

Built on this platform