I woke up last Tuesday to find my news dashboard already updated, four research topics processed into structured Obsidian notes, and a stale deploy cleaned up automatically. No human touched any of it. The agents handled everything overnight.
This is Platypus, an open-source platform I've been building since November 2025. It's not a chatbot. It's not a prompt playground. It's a self-hosted system where AI agents run on schedules, react to events, delegate work to each other, and remember what you care about across conversations.
This post covers what it is, how it works, and the trade-offs I made along the way.
Why chat-first AI tools fall apart for autonomous work
Most open-source AI interfaces are built around a single interaction pattern: you type a message, you get a response, maybe you attach a file. That's fine for one-off questions, but it breaks down the moment you want agents operating independently.
I wanted agents that could process a research queue every hour, sync results into my knowledge base, post a daily news summary, and clean up after themselves on a schedule. I wanted them to collaborate, with a parent agent delegating a research task to a specialist, getting the result back, then handing the write-up to another specialist. I wanted persistent memory so an agent remembers my preferences without me restating them every session.
Tools like Open WebUI are excellent chat interfaces. But they're fundamentally conversation-centric. Platypus is action-first. The chat interface exists, but it's one of many surfaces. The real power is in what agents do when nobody's watching.
The agent model: agents, skills, sub-agents, and memory
At the core of Platypus is a set of primitives that compose together. Rather than one monolithic "assistant," you build specialised agents and wire them into workflows.
An agent pins a provider, model, system prompt, tools, skills, and sub-agents into a reusable configuration. Select one in a chat and all of that loads. But agents also run headlessly via triggers, which is where things get interesting.
Skills work like they do in Claude Code or OpenCode. I have a blog-writing skill, a humaniser skill, one that teaches agents how to write good trigger instructions. The agent decides whether it needs a skill and requests it at runtime. You don't front-load everything into the system prompt.
Sub-agents let a parent hand off a task to a specialist with an isolated context and get the result streamed back. This is how I run complex workflows without bloating a single agent's context window with unrelated instructions. The parent doesn't need to know how the specialist works, just what to ask for.
Memory extracts facts and preferences from conversations in the background and injects them into future chats. The agent remembers your timezone, your project names, your preferences. Embeddings are generated from memories so agents can search for semantically related context from previous conversations, not just exact keyword matches.
The automation layer: triggers, boards, sandboxes, and dashboards
The second half of the system is about what happens without human involvement.
Triggers fire agents automatically. Cron triggers run on schedules (my news agent fires at 6:15am daily). Event triggers react to system events, so when a Kanban card moves to a specific column, the appropriate agent picks it up.
Kanban boards give agents a task management surface. Create cards, move them between columns, update descriptions. Combined with event triggers, this creates autonomous pipelines where agents process work items end to end.
Sandboxes give agents shell and filesystem access inside an isolated, per-workspace container. They can run arbitrary commands, write files, install packages. The backend is pluggable. Docker ships as the reference implementation, and the adapter interface is designed for contributions of other backends like E2B or Daytona.
Dashboards let agents surface data visually through metric widgets, charts, markdown panels, and weather displays. Agents update widget data autonomously via built-in tools. My news agent, for example, writes a markdown summary to a dashboard widget every morning before I'm awake.
TypeScript all the way down: Next.js, Hono, and Drizzle
The frontend is Next.js with ShadCN and Tailwind CSS, streaming responses via the Vercel AI SDK. The backend is a Hono.js REST API on Node.js handling agent logic, tool execution, and database interactions with PostgreSQL through Drizzle ORM. Shared Zod schemas between the two provide end-to-end type safety without manual synchronisation.
I chose Hono because it's fast, typed, and runs anywhere. Drizzle because I need raw SQL escape hatches for pgvector queries without fighting the ORM. Next.js on the frontend because, love it or hate it, the App Router and Server Components model works well for this kind of app.
Multi-tenancy from day one
Platypus has Organisations and Workspaces baked in from the start. An Organisation owns Workspaces, Providers, and member roles. Each Workspace is a scoped environment containing its own Chats, Agents, Skills, MCPs, and optionally a Sandbox.
I built it this way because I run multiple isolated contexts myself (personal research, project management, writing) and because multi-tenancy bolted on later is a nightmare. The data isolation is real, not just a UI filter over a shared table.
Provider agnosticism through the Vercel AI SDK
Rather than coupling to a single LLM provider, Platypus uses the Vercel AI SDK as an abstraction layer. You configure Providers at the Organisation or Workspace level with credentials, a base URL, and a list of enabled model IDs. Swap between Anthropic, OpenAI, Google, or a Bedrock-hosted provider without changing agent configurations.
Providers can also designate a cheaper model for one-shot operations like generating chat titles or extracting memory. You don't want to burn frontier-model tokens on metadata tasks.
How agents connect to external services via MCP
Platypus has first-class support for the Model Context Protocol. You register MCP servers at the Organisation or Workspace level and they resolve to tool sets at chat-turn time. This is how my agents interact with external services without me writing custom tool implementations for each one.
The MCP integration means Platypus grows its capabilities without bespoke tools for every service. If an MCP server exists for it, an agent can use it.
A real workflow: my automated research pipeline
Here's a pipeline I run daily that touches most of these primitives:
- I ask a general chat coordinator agent to add some research topics, which it delegates to a dedicated Kanban agent that creates the cards in the board's "To Do" column.
- An hourly cron trigger fires a research agent that picks up cards from "To Do," performs web research, writes findings to the card, and moves it to "Note Processing."
- An event trigger watches for cards entering "Note Processing" and fires an Obsidian agent that creates a structured note in my vault with proper wiki-links, frontmatter, and cross-references, then moves the card to "Done."
No human intervention after step 1. The agents handle the rest, including error recovery and retries.
Each agent in this pipeline runs on a provider and model suited to its job. The research agent uses a capable frontier model because it's reasoning over web results and synthesising findings. The Obsidian agent, by contrast, runs on a cheaper, less intelligent model since it's mostly shuttling pre-written content into the right place in my vault. Because providers and models are configured per agent, I'm not paying frontier-model rates for what amounts to structured file shuffling.
I also run the daily news summary agent I mentioned earlier. A separate cleanup trigger purges old news cards every two days so the board doesn't accumulate cruft. The whole system is surprisingly low-maintenance once the triggers are configured correctly.
No RAG, no multiplayer, no hosted version
I want to be upfront about what Platypus deliberately doesn't do.
There's no built-in RAG pipeline. Vector search is there (pgvector) and I use embeddings for memory retrieval. But a general purpose document ingestion system is a product unto itself. Instead, agents use sandboxes and MCP tools to process documents however they need to. The flexibility of "just run a script in the sandbox" beats a rigid pipeline for my use cases.
There's no real-time collaboration. Workspaces are single-user. Adding multiplayer would require CRDTs, presence, conflict resolution. The primary use case is personal agent orchestration, not team chat. Multi-tenancy gives you isolation between contexts, not collaboration within them.
There's no hosted offering. Platypus is self-hosted only. Docker Compose is the reference deployment story, and since everything ships as containers, any container platform works too (Kubernetes, ECS, and so on). You need a server, but you own your data entirely.
What's experimental and what's next
Platypus is a work in progress. I ship features most weeks. The sandbox system is experimental. Dashboards are experimental. Sub-agent delegation works but the developer experience can improve.
The pace of change is still high, with additional sandbox backends beyond Docker and improvements to the memory system on the roadmap.
The project is MIT licensed and contributions are welcome. If you're the kind of developer who wants AI agents that go beyond chat, that run autonomously, manage tasks, and integrate into your existing tools, I'd genuinely appreciate the help. Bug fixes, new sandbox backends, MCP integrations, ideas I haven't thought of.
Clone the repo, run docker compose up, and you'll have a workspace running in under two minutes. Head to platypus.chat to get started, and if you'd like to contribute, the source lives at github.com/willdady/platypus.
Platypus logo by Thiings.co.
Top comments (0)