For post-sales, FDE & product teams
Forward Deployed Agents
Turn customer engineering into a growth engine.
Spin up a dedicated agent for every customer account on your books. The agent knows that customer’s environment, runs your tools against it, and handles the work that does not need a human. Your engineers come in for the parts that do. Your team carries far more accounts without losing depth, and your customers integrate and grow faster.
Secure by design: isolated credentials, per-deployment memory, audited cross-company threads, observable runs, model flexibility, and privacy controls.
brew install ArchAstro/tools/archagentarchagent setup@ArchAstro staging Stripe webhook is firing twice on payment_intent.succeeded. We hit this in August. What was the fix?
The idempotency-key pattern in webhooks/stripe/handler.ts:47. After the Aug 14 incident you added a processed_events lookup keyed by event.id (commit a3f9c2d). Tuesday’s staging deploy rolled back to a pre-fix tag.
Re-deploy main to staging, or cherry-pick a3f9c2d. Want me to open the PR?
Nice catch. I’ll cherry-pick a3f9c2dto our shared paper-test repo and ping you when it’s live. Should be in under 10.
Let your team build, not integrate.
One agent per customer.
Use case 01
Customer Management
For Account Teams, SAs, ProServ, and FDEs
Drop agents into shared Slack channels. Your TAMs and AEs work in tandem with your agents to resolve post-sales issues and accelerate enablement.
@ArchAstro need a quick read for the Acme renewal review at 11.
Last 30d on Acme:
- API volume 4.2× (routing + webhooks)
- 2 open P2s:
webhook-retries(5d),cors-staging(12d) - 3 PRs queued for review (oldest 8d)
- Champion: Rob M, leading the
v0.9upgrade
v0.9 PR is up. Ready when you are. Walk through Thursday?
Use case 02
Embeddable Agents
For your customers and your FDEs
Your FDE or your customer embeds a scoped agent inside the customer’s coding harness. Troubleshoot in their code, in minutes, without leaving Claude Code, Codex, or Cursor.
Use case 03
Continuous Integration
For FDEs, SAs, ProServ, and your customers
Agents on both sides build integrations, migrate across versions, catch faults, and draft code-level fixes. Humans stay in the loop to tune, supervise, and approve.

Boundary model
Cross-company collaboration with privacy and security by default
Built-in schema protection, field guards, object level ACLs, and LLMJudge enable controlled sharing of only what is relevant between companies.
The bottleneck
Product ships continuously. Customer deployments lag.
Integration debt compounds. Per-tenant schemas, undocumented workflows, legacy format drops: all of it piles up on post-sales and forward deployed engineering teams, who do superhuman work moving, migrating, and stabilizing every account while onboarding the next.
Custom APIs per customer
Different auth flows, different schemas, different rate limits. Each integration is a new green field.
Legacy formats and drops
SOAP endpoints, SFTP folders, mainframe exports, vendor-specific CSVs. The stuff nobody documented.
Undocumented workflows
The real process lives in someone's head or a Confluence page last edited in 2019.
Unique data models
Custom objects, tenant-specific validations, and field mappings that break every assumption.
Works with coding agents. Codex, Claude, Cursor.
Extensibility via scripts, automations, and webhooks.
Quickstart
Zero to deployed agent in five commands
This is the real quickstart. The same commands your FDE team will run.
- 01Install
Install the CLI and plug in your coding agent
One binary. Works on macOS, Linux, and Windows. archagent setup wires the plugin into Claude Code and Codex so /agents:embed (Claude) or $archagents:embed (Codex) operates through any agent you deploy.
brew install ArchAstro/tools/archagentarchagent setup - 02Authenticate
Log in with your work email
Work email sets up your company workspace. Personal email addresses aren't supported.
basharchagent auth login you@company.com - 03Scaffold
Scaffold a project
archagent init creates a configs directory with agent, script, and workflow templates you can version in git.
basharchagent init - 04Install
Install a starter agent from the catalog
One command. The sample lands in your project, fully editable. Want to write your own? Drop in an agent.yaml and run archagent deploy agent agent.yaml.
basharchagent list agentsamples archagent install agentsample <slug> - 05Test
Start a session and send a prompt
create agentsession starts a one-off task. exec runs the prompt. --follow streams the run.
basharchagent create agentsession --agent $AGENT_ID \ --instructions "Help Acme resolve their webhook setup." archagent exec agentsession $SESSION_ID -m "Why is the signature check failing?" archagent describe agentsession $SESSION_ID --follow
The best of build and buy
A runtime your FDE team would build if they had the time
You focus on delivering value via custom agents; we take care of the cross-company runtime infrastructure. Every capability here is in the config you just deployed.
Agents as YAML
An AgentTemplate declares identity, tools, routines, and installations. Version it in git, review in PRs, roll back when a prompt regresses.
Per-customer isolation
Each customer agent has its own credentials and memory/long-termnamespace, scoped to your app and org. One noisy neighbor can’t leak into another.
Cross-company threads
archagent create threadopens a single thread with explicit, audited membership across orgs. Your FDE agent and your customer’s IT agent talk in one place.
Routines and automations
Handlers bind to real events: thread.session.join, thread.message_added, inbound webhooks, cron. Logic is a script, a workflow graph, or a preset.
Any model, per agent
A model: field on each AgentTemplate. Swap Claude for GPT-4o for a customer with a BAA. Model choice is config, not a rewrite.
Every run observable
Every tool call, retrieved passage, and LLM response is logged. archagent list agentroutineruns and describe agentsession --follow replay them after the fact.
Benchmarks
Built-in knowledge and retrieval, benchmarked and measured
Most agent platforms bolt memory onto a vector DB and move on. We publish results against four academic benchmarks instead. All results use GPT-4o as the answering model.
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% | ArchAstro baseline |
| LLM extraction + filesystem search | 86.0% | ArchAstro baseline |
| ArchAstro + GPT-4o | 94.8% | ArchAstro, Apr 2026 |
99.6% on assistant-stated facts vs 74% for LLM extraction methods. We index raw text rather than summaries.
Embeddable agents · how it works
Your agent, inside Codex, Claude Code, or Cursor
An embeddable agent is the ArchAgent you built, exposed through your customer’s coding harness. They install the ArchAgents plugin once, then a plain-English prompt is enough. Codex, Claude, or Cursor operates through the agent you designed, calls its tools, searches its knowledge, and answers from the same operating surface the live agent uses. Scoped, audited, revocable.
Run setup once from your terminal, restart Claude Code, then invoke embed inside Claude. From that point on, Claude discovers the agent's attached tools, skills, and knowledge, and answers from the same operating surface the live agent uses.
1. Install the local plugin
archagent setup2. Invoke embed inside Claude Code
/agents:embed3. Operate through your deployed agent
Use our Acme Deployment agent through the archagents plugin. Pull its tools and search corpus, then use them to debug why webhook signature validation keeps failing on Acme's staging env.
A support case that used to be “send us a HAR file and wait three days” becomes: the customer’s engineer asks Claude in their IDE, Claude runs your agent’s tool, the answer lands in their editor.
Execution layer
Code-level execution. Zero infrastructure overhead.
Every customer has one integration detail your YAML doesn’t cover: a Slack router, a webhook-signature check, a CSV schema that needs to be re-shaped before it hits the agent. In most platforms, that means standing up a new service. Here, it’s one file.
- Route inbound events. Send a Slack message to the right customer agent based on channel and handle.
- Validate before hand-off. Verify a webhook signature before the agent sees the payload.
- Reshape customer data. Map a tenant’s CSV columns into the schema your product expects.
- Trigger follow-ups. Post to a rollout thread when an integration test finishes.
agentscript runs inside the platform, binds to real events, and ships with typed namespaces for the resources you’d otherwise bolt together: threads, agents, users, slack, requests, email, jwt. No endpoint to host, no secrets to rotate, no container image to build.
let agents = import("agents")
let threads = import("threads")
let slack = import("slack")
let text = $.fields.text || ""
let channel_id = $.fields.channel_id || ""
let handle = $.fields.agent_handle || "concierge"
if (channel_id != "" && text != "") {
let agent = unwrap(agents.get({ agent: handle }))
let thread = unwrap(threads.ensure_by_key({
key: "slack:" + channel_id + ":" + handle,
title: agent.name,
agent_user_id: agent.id,
}))
threads.post_message({ thread: thread.id, text: text })
}FAQ
Common questions
What is a Forward Deployed Agent?
The AI extension of the role your customer engineering team already plays. A Forward Deployed Agent lives between you and one customer, with persistent memory of their environment, scoped credentials, and a cross-company thread your team and theirs share. Your FDE team designs the agent once and deploys one per customer. The agent does the deployment work that does not need a human; your team comes in for the parts that do.
Is this self-serve or enterprise-only?
Both. Sign in with a work email and we set up your company workspace on the spot — Team pricing applies by default. Enterprise lifts the scale caps, replaces the published rate with a negotiated contract, and adds hands-on support.
How is per-customer isolation enforced?
Every customer agent has its own credentials and memory namespace, scoped to your app and org. Nothing leaks between customers by accident. Agents can still collaborate across boundaries, but only through thread memberships you explicitly grant and we audit.
What can Claude or Codex actually do through my agent?
Operating through a deployed agent is deliberately narrow. You can only operate through agents inside an app you already have access to. Claude or Codex pulls the agent’s current tool and skill surface, lets you run those tools locally, and installs linked skills into the harness. It can’t bypass company boundaries, thread-membership rules, or existing approvals. Scoped, audited, revocable. Every session is logged with an impersonated_byclaim on the access token, so there’s always a trail.
Which LLMs can I use?
Any major model, configured per agent. A customer with a BAA can be on Claude while the agent next door runs GPT-4o. It’s one field in the AgentTemplate, not a fork of the runtime.
Will our data be used to train models?
No. Your data, your customers' data, and your conversations stay in your workspace. We don't train on any of it, and model calls are scoped per agent.
How much does it cost?
We're in private beta with design partners, so pricing is scoped to your customer volume and workload. Email us and we'll walk through what a workspace for your team looks like.
Where does the source live?
The CLI, example agents, and script-language reference are open source at github.com/ArchAstro/archagents. The platform runtime is closed-source today, but that’s the only piece.
Get started
Stop reinventing onboarding.
Start shipping agents.
One YAML file at a time. Or send us your hardest cross-company scenario and we’ll walk through what a workspace for it looks like.
brew install ArchAstro/tools/archagentarchagent setup