For product & engineering teams
Your conventions live in a wiki nobody's agent reads, your runbooks in a pinned Slack message, your incident learnings in a retro doc that's already stale. Estratos gives Claude, Codex, and Copilot one governed memory — scoped to the exact service they're working in.
The pain
Your coding agent doesn't know your conventions
An engineer asks Codex to add an endpoint and gets code that ignores the team's error-handling pattern, reaches for a library you migrated off last quarter, and repeats the exact mistake that caused last month's incident. The conventions exist — in a wiki, a retro, someone's memory — but the agent has never read them. So reviews catch what the agent should have known, again and again.
- Conventions and patterns re-explained in every prompt
- Runbooks that only the on-call who wrote them can find
- Incident learnings that never reach the next change
- Onboarding measured in weeks of 'ask someone who knows'
How Estratos maps your systems
Services, then projects
Model your platform as an ordered hierarchy: root → services → projects. A service's runbook attaches to its folder; an org-wide engineering convention attaches to a whole layer; a hard-won lesson attaches wherever it needs to apply.
A concrete example
root.payments.checkout-api
a scoped memory on one service: the deploy runbook and the idempotency rule for retries
layer: services
a layer-wide tagged memory: the team's error-handling and logging conventions, on every service
root.payments.checkout-api.refunds
a scoped memory on the project: the post-incident learning — never issue a refund without checking the ledger first
Point an agent at root.payments.checkout-api.refunds and it gets the service's runbook, the team's conventions, and the incident learning together — the context that change needs, in one bundle, in a fixed order.
A day in the life
The agent knows the convention before the review does
An engineer opens Codex to add refund handling to the checkout service and points it at root.payments.checkout-api.refunds. Estratos hands over the service runbook, the team's error-handling conventions, and the post-incident rule about checking the ledger first. The diff lands already following the pattern — the review is about the change, not about re-teaching the basics.
After shipping, the on-call learns something new from a near-miss and asks their agent to record it on the service. Because they're a Basic user, that write becomes a proposal in the review queue — a diff, visible only to them — rather than silently rewriting the team's runbook.
A maintainer reviews the proposed learning, tightens the wording, and approves it. Now the next engineer's agent — and the next incident responder's — inherits it automatically. A lesson learned once becomes a rule the whole team's agents follow, only after a maintainer signed off.
The governance payoff
Shared engineering memory is only trustworthy if changes are reviewed. Estratos treats that as the point.
Conventions change through review, not by surprise
Engineers propose; maintainers approve. An org-wide convention is tagged, so it needs an Owner to publish — a service-level runbook edit, any Admin. The broader the impact, the more senior the sign-off.
Every runbook is versioned
Each memory keeps its history with author and change type. See how a runbook or convention evolved, and roll back to any earlier version in one click. Deletes leave a tombstone — nothing is silently lost.
A record across web and MCP
Every MCP tool call and every memory change is in the audit log, with actor and time. You can see when an agent read the checkout runbook and when the refund rule was last changed — memory content itself is never logged.
Headless access for CI
For scripts and pipelines, mint a scoped API key and send it as a Bearer token — the same governed memory your agents read, available to your automation, revocable anytime.
Questions engineering teams ask
Can any engineer's agent overwrite a shared runbook?
No. Basic users propose; their agent's writes enter the review queue as a diff, visible only to them until a maintainer approves. Roles set the ceiling — a token can never exceed its user's role.
How does an agent get only the context for the service it's touching?
It calls retrieve with a path like root.payments.checkout-api. Estratos returns that service's scoped memories plus the tagged conventions for that layer — in a fixed order — and never a single memory in isolation.
Which agents and tools can connect?
Any Model Context Protocol client — Claude, Codex, Copilot, Cursor, and more — over one endpoint, plus scoped API keys for headless use. Connection details are in the MCP documentation.
Give your agents your team's memory
Start a 14-day trial, model your services and projects, and connect your first agent in minutes. No credit card required.