How it works
From a message in Slack to a fix hot-swapped into a running service.
Six stages of a single run, on one piece of work that touched five of your services. All of it inside your own cloud.
01
The trigger
Work starts where your team already works
A message in Slack, an issue moving in Linear, Jira or GitHub, a nightly schedule, or a person in the pane. You do not adopt a new place to ask for things.
Every path is the same path. Whatever starts a run, it is authorised against your roles first and lands on the same record.
Your tracker stays yours. It keeps priority, assignee and sprint. PlatformSmith keeps decomposition, attempts and execution state.
A run the system starts on its own cannot change anything. Only a real person’s request carries that authority.
Slack this run “/smith move checkout onto the v2 payments contract before the billing freeze”
PS
Replying in thread. Five services resolved, one work item created. I'll come back here when something needs you.
#platform-eng · started by a real person, not a bot
Your tracker An issue moving to In Progress starts the same run.
A schedule, a webhook, a person
Nightly scans, CVE sweeps, on-call alerts. Same path, same governance.
checked against your roles
bound to a work item
five services resolved
the run starts
02
Sequencing
A durable workflow takes it from there
The workflow owns the order of things: which service moves first, what happens in parallel, and where a person has to look before anything continues.
Retries and exactly-once execution, so a flaky step never becomes a duplicate change.
It can park for days at a human step and pick up exactly where it left off.
One change can fan out across every repository in a workspace when you need it to.
decompose
one work item, five services
resolve services
which repositories it touches
launch playbook
hand off to judgment
collect artifacts
attributable to each agent
await approval
parks for days if it has to
run e2e
against the real services
open pull requests
03
Coordination
Where judgment is needed, a playbook coordinates the agents
Sequencing is not judgment. When the work needs someone to read the situation and re-plan, the workflow hands off to a conductor that watches what the agents find and adjusts the plan around it.
A declared roster: one agent per service, each running the coding agent that team already uses.
Nothing is peer to peer. Every message between agents is routed through the platform, so the conversation is a record you can replay.
Barriers hold the group until the contract between services is agreed, so nobody builds against a shape that is about to change.
Participants
Billing
Claude Code Gateway
Claude Code Ledger
Codex Web app
Codex Agent to agent
routed through the platform · replayable
Gateway agent
The v2 intent needs an idempotency key on every retry. Can billing take it on the existing endpoint?
Billing agent
Existing endpoint. I will accept the key and ignore duplicates for 24 hours. Adding it to the contract now.
Platform
Contract recorded. Ledger and web app released from the barrier.
04
Execution
Each agent works inside its own sealed runtime
This is where the fidelity comes from. The runtime is injected into your own container image and becomes the main process; your real service runs as its child.
Your repository, cloned onto a branch at the commit the run pinned.
Your written method: prompts, subagents, skills, hooks and connectors, scoped from company down to project.
Secrets by reference, frozen into the runtime at launch. Never printed, never an environment variable, never visible to the agent.
Runtime
your service
child process
your image · sealed
One per service
Your service code Cloned from your repository onto a branch, at the commit the run pinned.
acme/billing · ps/checkout-v2
Agent definitions
Prompts, subagents, skills, hooks and connectors, scoped company to project.
“review like our staff engineer”
Secrets
Injected by reference and frozen at launch. Never printed, never in an environment variable.
not visible to the agent
A coding agent
Claude Code or Codex, whichever that team already uses.
the two your teams already use
05
The gate
You approve artifacts, not a transcript
The output of a run is a set of artifacts, such as a contract change, a migration plan or a test plan, each attributable to the agent that produced it and the definition it worked to.
Approve, and the other services continue. Send it back, and they hold.
The run can wait days for you without losing its place.
The approval is the compliance record: who asked, which agent acted, what changed, who signed it off.
Contract change across five services
billing · gateway · ledger · web app · reporting
Claude Code
Migration plan and rollback
reviewed against your standards
Codex
Test plan for the refund path
written from your definition of done
Claude Code
Waiting for you
Four other services are holding on this one.
Send back Approve
06
Proof
Proven end to end, then hot-swapped into the running service
Your services already carry the runtime in your dev environment, so the end-to-end test runs against the real thing rather than a reconstruction of it.
A failure is picked up in the same environment by the same agent, without handing the problem to a person first.
The fix is rebuilt and swapped underneath the running service. The pod never restarts and the main process never changes.
The build runs before the stop, so a broken build is a no-op rather than an outage.
Billing hot-swapped
runtime + your service
Gateway healthy
runtime + your service
Ledger healthy
runtime + your service
Web app healthy
runtime + your service
Reporting healthy
runtime + your service
End-to-end across the five services one failure in billing · agent picked it up
lock
build
stop
swap
start
health check
the pod never restarted
Watch it run on your own stack.
Thirty minutes, a real multi-service change, nothing pre-recorded.