These are products SoftwareDepo is building — not services we sell today. Each began as engineering we kept repeating for clients, and each is documented as a full specification before a line of production code is written.
We publish them for two reasons: the architecture is often the useful part of a conversation, and we would rather be judged on how we think than on a feature list. Every page below states plainly that the product is in development.
AI Platform and Governance
- AgentOS: Production AI Platform — the shared platform for designing, evaluating, releasing and observing enterprise agents.
- Enterprise MCP Gateway and Registry — one governed, audited path between AI clients and business systems.
- Desktop AI Skills and Workforce Manager — turning individual desktop-AI expertise into a company capability.
Engineering Knowledge
- Project Genesis: Engineering Memory — twenty years of project directories made searchable, with citations.
If one of these solves a problem you have now, tell us about it — early conversations shape what gets built first, and we will be straight about timelines.
What “In Development” Means Here
Take the label at face value. Nothing listed above is something you can buy, license, subscribe to, or deploy today. These are products in development. There is no order form behind any of these pages, no trial, no waitlist, and no pilot to join.
What exists is a written specification. Reading one of these pages tells you how we would build the thing and which parts we think are hard. It does not tell you when it will be available, because we do not know.
If you arrived looking for something to evaluate this quarter, there is nothing here to evaluate. The AI development services pages cover the work we take on under contract, and that is the part of this site you can engage today.
Why Publish a Specification Before the Product Exists?
Architecture travels. A team deciding whether to build an internal agent platform or wait for something off the shelf mostly needs to know what the parts are, which parts are difficult, and which are a weekend of plumbing. That conversation has value whether or not we ever ship.
There is a cost to publishing this way. It commits us to a design in public and invites anyone to copy it. We think the trade is worth taking, because the difficult work sits in implementation, operations, and the unglamorous edge cases, well past the diagram stage.
What Each Specification Covers
AgentOS: Production AI Platform is specified as a control plane: one place where an agent would be designed, evaluated, released, and watched once it is live. Enterprise MCP Gateway and Registry would sit at the boundary, giving an agent a single governed path to a business system, with a separate credential for each tool it can reach, an audit record written per call, and an approval step in front of writes.
That approval step is the part of the gateway design we would not trade away. Any agent that reads outside content and can also call a tool has an instruction path running from that content into your systems, and a support ticket or a supplier PDF is a perfectly good place to hide an instruction. The Technologies page covers the defenses in full.
Desktop AI Skills and Workforce Manager addresses the people layer, where individual fluency with desktop AI tools stays trapped with the individual. Project Genesis: Engineering Memory is specified as retrieval over project history, returning a citation to the source file so an answer could be checked by someone who doubts it.
Where the Designs Overlap
The overlap is deliberate. A gateway audit log is what would make platform observability worth reading. An evaluation harness is as useful pointed at a retrieval system as at an agent. They are specified apart because an organization could reasonably want one of them and none of the rest, and a design that only works once everything is adopted at once is a design we would not trust.
What Is Settled and What Is Still Open
The parts we treat as settled are the ones that would be expensive to change later: the gateway’s audit record and approval model, the separation between read and write paths, and the decision that evaluation sets live in your repository and not in a vendor’s console. The parts still open are mostly about where policy belongs, how much of it a gateway should enforce and how much should sit with the calling agent. Specifications change when they meet real constraints, and none of these has met one yet.