ArchAgentsPlatform and security
Your customer keeps the keys
The agent runs inside their organization, under their credentials and their approvals. You never ask for access to their systems.
Your company
Versioned config, in git
Your customer
Runs in their org, on its own
The install wires one shared workspace across the seam. It is the only thing that crosses, and your team steps in through it when the agent needs a human.
Follow a request
What happens when the agent gets to work
- 01
Trigger
A request lands in the shared thread, or an event fires
- 02
Isolation
It reads only that customer's data, with its own credentials
- 03
Knowledge
It pulls the history that matters and drafts a reply
- 04
Field guards
The draft is checked before it sends. Leaks get blocked or redacted
- 05
Approval
Anything that changes their systems waits for a human yes
- 06
Audit
It ships, and every step is logged and attributable
- 07
Escalation
If it needs a person, it brings your team into the shared workspace
Isolation
One agent per customer, and it reaches nothing else
Two companies work on the same job without either one handing over the keys.
- Each agent runs with its own credentials and memory, scoped to one org.
- Every read is filtered to that org in the query itself. It is the default for every lookup, not a check someone remembers to add.
- Anything crossing between the two companies goes through a thread or team you grant, and nothing else.
- Access can be pulled at any time, and you can rehearse against a sandbox before anything touches production.
Field guards
Every reply is checked before it crosses
You write the rules on the agent. Fast checks run first, in milliseconds: exact strings, any-of lists, regex. Then a language-model judge reads the draft for the leaks a pattern would miss.
- On a hit the reply is blocked, the field is redacted, or it is flagged for review. Your rules decide which.
- Put judges from two model vendors on the same field. A jailbreak that fools one still has to fool the other.
- The checks run after the agent writes, so it cannot argue its way past them. A blocked reply never reaches the thread.
- The rules live in the agent’s config, versioned and reviewable like the rest of it.
Approvals and audit
Nothing changes without a person saying yes
Your customer never manages a platform. They ask in plain language, from the Slack thread you share or their own coding agent, and they see everything it did.
- Sensitive actions pause for a human on their side before anything is written.
- Every step is logged and attributable, so both security teams can see what was done, by which agent, and when.
- A sandboxed agent is refused promotion at the data layer, so a test can never touch a live account.
Knowledge
Agents remember each customer
In a long cross-company thread the agent pulls up the decision you already made instead of asking your customer to repeat it. Search runs on meaning and on exact words at once, walled to one customer’s org in the query itself. Here is how it measures against published baselines.
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.
The alternatives
Why not hand your customer access some other way
You can build any one of these on an API key, an MCP server, or a single support bot. Each customer has a bespoke environment, and docs and scripts do not survive contact with it.
| An API key | An MCP server | One global support bot | ArchAgents | |
|---|---|---|---|---|
| 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, upgrades opt-in per customer | partial | partial | – | ✓ |
| Every reply checked before it crosses | – | – | 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.
Check our work
Ask your own agent instead of trusting this page
Point the coding agent you already use at this site and our docs, and have it pull the answer for your role. We publish an llms.txt so it gets the plain facts.
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
Pick where agents start working
Compliance
SOC 2 in progress. Every action is logged and attributable, and access is revocable in seconds.
Get started
Map one workflow with us
Bring one account that keeps needing your engineers, and we will walk the boundary with you.
Calls are with a founder, not a sales team.