For enterprise engineering teams
Manage the fleet.
Govern the work.
Prove the result.
Manage, orchestrate, govern, and implement secure Agentic Software Development and Operations at scale.
- Runs in your own cloud
- Claude Code and Codex, together
- Approval gates you define
- Every step on the record
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
An agent that can only see one service can't finish a change that spans five.
Nobody can see the whole picture
Parallel agents, no shared view. No single place to check what’s underway or what needs a decision.
Sandboxes aren't the real thing
Agents that work in a clean-room environment produce changes that pass there and break in production.
Getting one agent to work unattended is a question of loops. Getting five to finish one change together is a different question — and 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 hot-swapped into a running service.
Three of the six stages of a single run, on one piece of work that touched five 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
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.
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.
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
Capabilities
Six things, one control surface.
Orchestrate
Durable runs that retry, never repeat a step, and can wait days for a person without losing their place.
Coordinate
Many agents on one piece of work. Every message between them routed through the platform, and replayable.
Govern
Approval gates where you want them, deny-by-default access, and nothing the system starts can change anything alone.
Execute
Agents work inside your own image against the real service. Changes swap into the running service without a restart.
Record
Work items, attempts and artifacts instead of a chat transcript. Your tracker keeps priority, assignee and sprint.
Surface
One pane over every run, plus Slack and the assistant your team already uses.
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.
FAQ
Questions we get asked.
If yours isn’t here, ask us on the call.
Do we have to change how our services are built?
No. PlatformSmith works with the setup you already have. There’s no migration and no new format to adopt.
Where does our code go?
Nowhere. The platform runs inside your own cloud or data centre.
Which agents does it support?
Claude Code and Codex today. You can mix them across teams, and change your mind later.
Do agents merge code on their own?
Only if you decide they should. You set the level of independence per team, per service, or per kind of work, and you can require a human approval anywhere.
How is this different from an AI coding assistant?
An assistant helps one developer in one repository. PlatformSmith runs many agents across many services and coordinates the work between them.
How long does it take to get started?
A first service in an afternoon. A meaningful multi-service workflow within the first week.