Always-on agents that get smarter over time. Open source, MIT.
SERVICES AGENT READY
Your customers have started working inside Claude, Cursor and ChatGPT. If your software cannot be called from in there, the work goes to whoever can. This is not an agent for your product. It is the set of surfaces that lets everyone else’s agents use the product you already have.
Nothing here replaces your product. It gives an agent a way in.
The front door every assistant already knows how to open.
Your API, exposed as tools any Model Context Protocol host can mount: Claude, Cursor, and the rest. We have written the bridge that mounts other people’s MCP servers, so we have met the ways they go wrong. Yours will handle reconnects, keep its tool names stable, and not leak your environment into a subprocess.
Procedures an agent loads when it needs them.
A tool says what a call does. A skill says how your product is actually used, which is the part your support team knows and your docs bury. We ran the conformance pass against the Agent Skills spec for our own runtime and published where we differ, so yours will be written to the standard rather than to one vendor.
Most legacy APIs are usable, not legible.
Errors that say what to do rather than what went wrong. Idempotency, so a retry is safe. Pagination an agent can follow without guessing. Auth it can carry, with scopes narrow enough that granting one is not granting everything. This is usually the least glamorous half and the one that decides whether any of it works unattended.
Agents are good at terminals.
For anything developer-facing, a command line is often the cheapest surface you can give an agent and the easiest for a human to check afterwards. It also gives your own engineers something they will use, which is how these things survive past the engagement.
A server nobody can discover is a server nobody has.
Listed where hosts and their users go looking for MCP servers, with a description written for someone deciding in four seconds.
Submitted to the app and connector directories the major assistants run, and through whatever review each one requires.
The integration listings for the platforms your customers are on, updated to say that your product now works from inside an agent.
This half is distribution rather than engineering, and it is the half that usually gets dropped. It is the difference between having built the thing and your customers being able to reach it.
01
We try to drive your product with an agent and write down everywhere it fails. You get that document whether or not you hire us for the rest of it.
02
The server, the skills, the API changes and the CLI, in your codebase and through your review process. Scoped from the audit, so it is the short list rather than everything.
03
Into the registries and directories, with the copy written and the review answered. Then your engineers own all of it.
We did all of it to our own runtime first, in public, and you can read the commits.
Stratus Agent mounts any MCP server as tools under its own policy. Building the host is how you learn what makes a server good to mount.
We ran our skills against the Agent Skills standard, fixed what differed, and wrote down the rest. Very few people have done that pass.
Our search contract ships no backend on purpose, so any vendor can implement it. That is the same problem as designing your surface.
View on GitHub ↗Whatever it does next is the audit. Send us what happened.