Agentic software development platform
Manage the fleet.
Govern the work.
Prove the result.
Your coding agents, working across every service, with one record of everything they do.
- Agents run on your infrastructure
- Claude Code and Codex, together
- Gates you define
One request just now
slack · #platform-eng
Move every service onto usage-based billing before the pricing launch.
JIRA-4812 
5 repos reading tracker · 5 services touched · no ticket split needed
Decomposed and assigned 5 strands · 3 agents
queued
queued
queued
queued
queued
runtimes launching in your cloud · credentials frozen at launch
Agents working in parallel 3 running · 8m elapsed
merged
running
running
running
queued
context shared 14× between agents · every message replayable
Paused at your gate 4 / 5 merged · 1 waiting
merged
merged
merged
merged
gate: your call
Schema change needs your approval The run waits here as long as it takes. Nothing merges without you.
Review diff Approve
approve and the run finishes itself · full record exported
The wall
Agents stop at the service boundary.
Background agents work inside one repo. Your software doesn't.
Service boundary
done
done
carried over by hand
blocked
done
done
Work stops at the boundary
One agent, one service. The change spans five.
Nobody can see the whole picture
Ten agents running, and nowhere to see all of them at once.
Sandboxes aren't the real thing
It passed in the sandbox, then broke in production.
Getting one agent to work unattended is a question of loops. Getting five to finish one change together is a different question. The industry has started calling it graph engineering.
What that meansThe platform
One place to run, coordinate, and govern your agents.
Give it the outcome you want.
It assigns the right agents to the right services, lets them share what they learn, pauses for your approval at the moments that matter, and records every step. It runs on your infrastructure, against your real systems, following the way your team already works.
Work arrives from
GitHub Issues Jira 
Linear 
Slack The UI
An MCP client
A schedule
Your API
Your cloud · AWS · GCP · Azure · on-prem
Decide and govern
sequence the work, hold the gates, keep the record
Durable workflows
Agentic playbooks
Work items
Approval gates
Access control
One pane
Run with production fidelity
your own image, sealed per service
Docker 
Kubernetes Gateway
Billing
Web app
Agents do the work
under the method your team writes down
Claude Code 
Codex Your written method
skills
subagents
hooks
MCP servers
How it works
From a message in Slack to a fix in a running service.
Three of six stages. One piece of work, five services.
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.
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
Coordination
Where judgment is needed, a playbook coordinates the agents
Some steps need more than a fixed order. 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 as it goes.
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.
03
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.
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
Capabilities
Six things, one control surface.
Orchestrate
Runs that wait for you, and never repeat a step.
Coordinate
Agents talk. Every word is on the record.
Govern
Nothing ships past a gate you didn’t open.
Execute
Inside your image. Against the real thing.
Record
Work, not transcripts.
Surface
One pane. Every run.
Plugs into GitHub Jira Linear Slack Docker Kubernetes Claude Code Codex
GitHub Jira Linear Slack Docker Kubernetes Claude Code Codex Who it’s for
Built for the team that owns the platform.
Platform engineering
give every team a governed way to use agents, instead of ten teams inventing ten of them.
Engineering leadership
see what agents are doing across the organisation, in one place.
Security and compliance
approve the rules once, then get an audit trail that proves they held.
Watch it run on your own stack.
Thirty minutes, a real multi-service change, nothing pre-recorded.
We already use Claude Code and Codex. What does PlatformSmith add?
Claude Code and Codex are the agents. PlatformSmith is what runs them together. It splits one piece of work across services, routes and records every message between agents, and keeps a run waiting for your decision for as long as it takes. A coding assistant helps one developer in one repository. This runs the whole fleet.
Which coding agents does PlatformSmith support?
Claude Code and Codex. You can mix them in the same run, with Claude Code on one service and Codex on another.
What can an agent do without approval?
What you let it. Approval gates are explicit steps in a run; a run parks at one for up to seven days and resumes where it stopped. A run the system starts by itself, from a schedule or an alert, can’t change anything. Only a request from a real person carries that authority.
Where does PlatformSmith run?
The runtimes, where your code executes, run on your infrastructure. The control plane is ours, in AWS Ireland (eu-west-1). Your side dials out over one outbound connection; we never dial in.
Does our source code leave our environment?
Agent calls go straight from your runtime to your model provider. That traffic never passes through us. We do keep a full session transcript in the EU so you can watch, resume and review, and it contains code. It is not redacted yet.