The model layer is moving quickly. New models will keep getting stronger, more specialised, more expensive, and more constrained by the policies of the companies that serve them. That is useful progress, but it is not a stable foundation for how a team should run its work.
d5s is built for the layer above the model: the workspace where agents use memory, tools, files, approvals, sandboxes, and audit trails to do real work inside a team environment.
Our mission is simple: any model, any cloud, your infrastructure.
The model is a component
A model is essential, but it is not the product. The product is the system around it: the context it receives, the tools it can use, the permissions it has, the traces it leaves, and the way it improves with feedback from the team using it.
That system should not be tied to one provider. Different tasks need different models. Some work deserves the strongest hosted model available. Some work should run on a cheaper utility model. Some customers need an open-weight model, a private deployment, or a provider mix that keeps no single endpoint on the critical path.
d5s treats model choice as a runtime decision, not a product identity.
The workspace goes where the work is
Serious teams already have infrastructure: source control, databases, object storage, queues, identity, secrets, observability, review paths, and compliance boundaries. An agent that cannot operate inside that environment is a demo. An agent that bypasses those controls is a liability.
d5s is designed to meet customers where their work already runs. Use a managed deployment when speed matters. Use dedicated cloud infrastructure when isolation matters. Bring the runtime closer to your data when governance requires it.
The workspace should feel managed without forcing every customer into the same infrastructure boundary.
Quality is the whole system
Quality is not only whether the base model scores well on a benchmark. In an agent workspace, quality is whether the agent picks the right tool, asks before irreversible actions, preserves project context, recovers from failures, spends expensive tokens only when needed, and leaves a trace another teammate can understand.
That is why d5s focuses on the runtime around the model: context composition, model routing, tool execution, memory, sandboxing, permissions, evals, and human review. The agent should feel reliable because the system is reliable.
Open where it matters
Teams need to inspect and control the boundaries that matter: how data enters the workspace, which models can be called, where tools run, what memory is stored, and what happened during an agent session.
Openness is also how learning compounds. If teams can see what the agent did, they can correct it. If corrections become structured signal, the workspace can improve. If that learning belongs to the workspace rather than one model endpoint, customers can keep improving while the model market changes around them.
What we are building
d5s is an agent workspace for teams that want AI to touch real work without surrendering control of their stack.
The non-negotiables are:
- Model choice. Use the model that fits the task, policy, budget, and deployment boundary.
- Deployment choice. Run managed, dedicated, or inside customer-controlled infrastructure.
- Portable memory. Keep project and organisation context structured, scoped, inspectable, and durable across model changes.
- Tooling with boundaries. Give agents real tools with permissions, secrets, isolation, and audit trails.
- Human control. Keep approvals, review, rollback, and provenance in the flow of work.
The next phase of AI work will not be defined by a chat box. It will be defined by the workspace where models, tools, memory, and people operate together.
That workspace should belong to the team.
Any model. Any cloud. Your infrastructure.
That is the mission of d5s.