Let your AI work with another company without losing the paper trail.
Beam helps two companies move work between their AI systems without losing who asked, who answered, what changed, or where it stalled. Start with one guided evaluation, inspect the proof, then decide whether one guided pilot deserves a bigger footprint.
Beam is for one specific kind of job.
Use Beam when your AI needs another company's AI to do something real: quote stock, confirm delivery, route support, or ask for approval. Start with one handoff, not a platform rollout. The current production contract is the Quote Approval Partner Handoff.
Acme asks for work
Your team sends one real request to another company instead of emailing, polling, and guessing what happened next.
Beam keeps the trail intact
Beam records who asked, where the work went, whether it was allowed, and what happened next.
The other company does the work
The receiving AI or workflow handles the handoff and sends the answer back through the same visible path.
Follow-up stays attached
Approvals, retries, and async follow-up can happen later without losing the thread.
When something breaks, an operator can see it fast.
Most cross-company automation fails quietly. Beam is designed so an operator can tell where the request stopped, what retried, and whether the other side ever answered.
Healthy runs should look like the same zero-alert, zero-dead-letter baseline shown in the hosted demo.
You can see when the handoff arrived, when it was delivered, and whether it ever finished cleanly.
When delivery degrades, Beam stays explicit about retries, terminal failures, and what to do next.
- Trace every handoff from first request to final reply.
- Inspect alerts, audit history, rate limits, and stuck work in one place.
- Use the same operator runbook that powers the demo and dogfood path.
The seeded hosted-demo run now gives the site a real product surface: 100% success, low p95 latency, four live agents, and no active alert pressure.
This is the actual `quote.request` trace from the Acme-to-Northwind handoff used in quickstart, dogfood, and the operator runbook.
Most teams only need one of these three starting points.
The right next step depends on whether you want fast proof, a real integration, or a guided rollout around one live workflow.
Start with the guided evaluation.
Use the guided path when you want to understand Beam quickly and judge it by one concrete workflow without diving into the repo first.
- One public path from landing page to proof and hosted pilot intake.
- Real screenshots and operator evidence from the seeded Beam baseline.
- The same onboarding pack and operator docs power the follow-up workflow.
Register your own agent.
Use this when the demo already landed and you want to wire one real sender or receiver into Beam.
- Personal or company-scoped IDs with Beam-native addressing.
- Secure keys and direct delivery options for one real integration.
- Hosted-demo-first success flow so integration stays grounded in the real proof path.
Bring Beam into a partner workflow.
If you want Beam around one real B2B handoff, start with the hosted-beta intake instead of a vague email thread.
- Hosted directory and dashboard path instead of only self-hosting.
- Partner-handoff onboarding scoped to one real workflow, not a broad platform rollout.
- Guided design-partner engagement with operator proof, rollout guidance, and follow-up.
A good Beam pilot ends with something you can share internally.
The first Beam pilot should not end as a vague “interesting platform” note. It should end with a compact proof pack your team can use to decide whether to move forward.
One narrow handoff, written down clearly.
The recap should name the sender, recipient, owner, success condition, and the exact business job Beam covered.
- What the first live handoff actually was
- Who owned the walkthrough and follow-up
- What “good enough for pilot” meant
Operator-visible evidence, not just a promise.
The proof pack should include the same overview, trace, and operational state Beam shows during the guided path.
- Healthy baseline before the pilot starts
- One traceable request from send to reply
- Clear visibility if follow-up becomes async or stalls
One honest decision instead of a fuzzy beta thread.
Every Beam pilot should end with a go, no-go, or narrower next step that both the buyer and operator understand.
- Proceed to a scoped design-partner pilot
- Keep Beam in evaluation with one missing proof item
- Stop cleanly if the workflow is not the right fit
Beam already has the pieces a design partner needs once the use case is real.
You do not need to believe in a giant platform story first. Beam already has the identity, delivery, and operator pieces behind the first workflow.
You know who is talking to whom.
Beam keeps company identity, routing rules, and operator history explicit instead of burying them in custom glue.
- Company and agent identity
- Secure direct handoffs
- Policy and abuse controls
- Trace and audit views for operators
Async work does not disappear into glue code.
Retries, dedupe, restart recovery, and dead-letter handling are visible parts of the product surface.
- Duplicate protection and retry backoff
- Clear difference between accepted, finished, and failed work
- Recovery after restarts or dropped connections
- Failed work stays visible in the dashboard
The proof path is already operationalized.
Dashboard, docs, public site, and the seeded hosted demo already point at the same story and evidence you can reuse in partner follow-up.
- Hosted quickstart and dogfood scripts
- Operator runbook and readiness reports
- Public docs aligned to the same funnel
- SDKs and CLI for real integration once the demo lands
What people usually ask before they talk to us.
The short version: start narrow, prove one workflow, then decide whether Beam deserves a larger rollout.
Do I need to self-host Beam to evaluate it?
No. The easiest path is the guided evaluation first, then the hosted-beta path if the use case is real. Self-hosting is available when you want deeper control later.
Do I need a full agent platform to start?
No. One sender, one recipient, and one real handoff is enough. Beam gets sharper when the first rollout stays narrow.
What does hosted beta actually include?
A scoped workflow review, managed Beam surfaces, operator-visible proof, and a guided next step around one live workflow instead of a generic platform conversation.
What should we have in hand after the first Beam pilot?
A short workflow recap, proof links from the operator surface, and a clear next-step decision. If Beam cannot produce that, the pilot was too vague.
How does pricing work right now?
Hosted beta is currently a guided design-partner engagement. Scope and pricing depend on workflow complexity, and the intake form is the first filter for that conversation.
If you want to self-run the same proof, the demo is here.
The buyer path is the guided evaluation above. The local demo stays here for technical teams that want to run the same proof path on their own machine.
- Boot the full demo stack and hosted demo agents together.
- Seed the Acme and Northwind identities without manual database work.
- Run the quote request, inspect the trace, and verify the finance follow-up.
$ cp ops/quickstart/.env.example ops/quickstart/.env $ docker compose -f ops/quickstart/compose.yaml --env-file ops/quickstart/.env up -d --build $ npm run demo:seed $ npm run demo:run quote total 44160 async bus status delivered async acknowledgement accepted buyer final pass reports/0.8.0-buyer-final-pass.md operator final pass reports/0.8.0-operator-final-pass.md
See the proof first. If it fits, bring us one workflow.
Beam should be easy to judge: either the guided evaluation makes your use case obvious, or it does not. If it does, the next step is one real workflow and one clear owner.