ArchAstroArchAgents

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.

Install and use with Codex, Claude, Cursor
brew install ArchAstro/tools/archagent
archagent setup

Let your team build, not integrate.

One agent per customer.

CompressDiscovery
AccelerateIntegration
ShortenTime-to-Revenue

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.

Shared context and collaboration, in real time.

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.

One command to embed. Works in any harness.

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.

Activity feed showing routine runs and triggered events for Customer Success Helper
Every run is observable. Every fix is reviewable before it ships.

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.

Diagram showing two private company spaces connected by a trusted shared team and thread

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.

DefineConfig
TestSandboxes
ObserveRuns

Quickstart

Zero to deployed agent in five commands

This is the real quickstart. The same commands your FDE team will run.

  1. 01
    Install

    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/archagent
    archagent setup
  2. 02
    Authenticate

    Log in with your work email

    Work email sets up your company workspace. Personal email addresses aren't supported.

    bash
    archagent auth login you@company.com
  3. 03
    Scaffold

    Scaffold a project

    archagent init creates a configs directory with agent, script, and workflow templates you can version in git.

    bash
    archagent init
  4. 04
    Install

    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.

    bash
    archagent list agentsamples
    archagent install agentsample <slug>
  5. 05
    Test

    Start a session and send a prompt

    create agentsession starts a one-off task. exec runs the prompt. --follow streams the run.

    bash
    archagent 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.

ConfigurationAccuracySource
LLM extraction + hybrid RAG83.6%ArchAstro baseline
LLM extraction + filesystem search86.0%ArchAstro baseline
ArchAstro + GPT-4o94.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

shell
archagent setup

2. Invoke embed inside Claude Code

Claude Code
/agents:embed

3. Operate through your deployed agent

Prompt · paste into Claude Code

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.

agentscript · slack-router.script
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/archagent
archagent setup