Why we built Platos

We are Winsen Labs. We build agents for ourselves and for teams who hire us. We have been doing this for a while.

Every project started the same way. We needed a model, a tool gateway, a memory layer, an evals harness, an observability stack, multi-tenancy, queue isolation. We needed the agent to call our backend over a stable contract. We needed approvals for sensitive operations. We needed to know what tools the agent saw on every turn and which one it picked, every time.

Each time, we rebuilt these. Each time, we got something fragile. Each time, the team ended up firefighting a memory bug or an unhandled rate limit at 3am instead of shipping the actual feature.

We tried Claude's managed agents. The hosted experience is good. But it locked us out of self-hosting, locked us into one provider, and locked us out of our own data. For internal teams that handle real customer workflows, that is not a serious option.

So we built Platos.

It is the agent runtime we wished existed. Open source, Apache 2.0, self-hostable in five minutes. Bring your own provider keys (Anthropic, OpenAI, Google Vertex, Voyage, anything else you wire up). Own your data, including memory and conversation history. Run agents alongside your durable background jobs on the same trigger.dev engine.

We use Platos every day. The chat agent that answers questions on this site is running on it. The internal agents we run for ourselves and our customers run on it. The dashboard you see in the screenshots is the dashboard we use.

This is v1. It is rough in places. The error messages can be better. The docs will fill out over the next few weeks. The hosted demo at play.platos.dev is a trial environment, not a production tier. Self-hosting is the recommended path for any real workload.

If you find Platos useful, star the repo, file issues, send pull requests. If you want us to design or build internal agents for your team, hello@winsenlabs.com.

Tejas Parthasarathi Sudarshan and the Winsen Labs team