Deriv One is built by Ansh Choudhary, Aditya Singhal, Joel Joseph, Sejal Chopra, and Khirthana Sundaram. This is part 1 of a three-part series on building and open-sourcing Deriv One.
Our CEO, Rakshit Choudhary, asked for a skills registry. On paper, that’s a solved problem: you browse, you install, and you’re done. It turned out not to be the problem at all.
Agents were already spreading across Deriv, and every team that was building one was writing its own skills for it. One team started a shared repository; before long, every team had its own, each with a different idea of what a skill even was. Nobody was short on skills. What nobody had was a way to say who could run which one, and a skill that touches internal systems or finance data can’t sit in an open repository next to a harmless health-check script. Discovery was never the problem. Control was.
That question became Deriv One, an open-source, self-hosted AI platform that gives a whole company governed access to AI. It combines a shared skills catalogue, registered Slack agents, an editor-style workspace, sandboxed code execution, and a no-code app builder, all running on one identity directory and one secrets vault, with usage tracked against your own model gateway. Deriv has released it as open source under the MIT licence, under the neutral name Platform, so you can put your own name on it.
From a registry to a platform #
If your company’s early AI adoption looked anything like ours, you’ll recognise what came next. A handful of people moved fast and built something real, while everyone else stalled around configuring their first integration. In a regulated business, there’s a second wall behind that one: finance and compliance teams need full capability, but you can’t run a security review every time someone wants to try something new.
A few of us sat down in Rakshit’s office to work out what the registry should look like, and I walked out with the problem turned inside out. Skills needed to be gated by job function, and people needed to use them without first building an agent of their own. We could have made it safe by taking capability away, and we decided that was the wrong move: take the power out of the tool, and people go back to whatever they were using in private, where nobody can see or review it. So we built the guardrails into the platform and made sure the approved way was also the easy way.
Once that was the real brief, a browsing interface on top of a GitHub repository was never going to hold up. Chris, Ansh, and I went away and asked a different question: why not build a workspace? One that onboards you the day you join, pulling your department and access from the HR system, so it already knows who you are and what you’re allowed to touch before you’ve typed a message.
When I showed Rakshit what we’d built, his first words were “this is exactly what I wanted.” It wasn’t a registry any more. It had become a platform with four parts.
What’s in Deriv One: Workspace, Skills, Agents, and Lab #
Deriv One has four main surfaces. They share the same skills, agents, identity, and secrets.
Workspace
Most AI tools give you one conversation at a time. Real work spills across several: a draft in one window and the policy you’re checking it against in another.
The Workspace behaves more like an editor than a chat app. Split panes let you run several conversations side by side, and anything the assistant produces (markdown, an HTML preview, a spreadsheet, or code) opens as a tab next to the conversation that made it. It saves your layout, so the next morning everything is where you left it.
Typing @ in the composer attaches a skill to your message, much as you’d mention a colleague. A context meter shows how much of the model’s window you have left, which stops long threads failing without warning. Behind the scenes, a complexity router sends greetings and quick lookups to a fast, cheap model and escalates to a stronger one when a request needs proper reasoning or the first answer falls short.
Partway through a conversation, the assistant can suggest turning what you’re doing into a skill, an automation, or a Lab app. It drafts the thing; you review it, edit it, dry-run it, or bin it, and nothing exists until you approve it.
Skills
A skill is a markdown document that sets out how to do a task, when to use it, and when not to. Reviewers approve each one before it reaches the catalogue, which keeps its full version history and shows people only the skills their role allows.
Suppose someone in Payments works out a reliable way to investigate a particular kind of client query. Once it’s a skill, the next person can install it in one click instead of working it out again. Part 2 covers how review, routing, and permissions work underneath.
Agents
Agents are persistent assistants, each with its own persona, model, and skills, and optionally a memory and a private knowledge base. You can register one in the interface or as its own Slack app, with its own credentials and only the Slack permissions its job requires.
Every agent has a named owner and reviewed scopes. That sounds bureaucratic, but it’s what lets teams run their own agents without anyone pasting a shared API key into a config file.
Lab
Lab is for when a team needs a small internal tool and would otherwise have to file a ticket for it.
You describe what you want in plain language, whether that’s a dashboard, a form, or a calculator. Lab picks a stack to match (a static page for simple things, Python or React for anything heavier) and attaches approved skills from your catalogue, so the app calls capabilities you’ve already vetted rather than building its own integrations.
Building happens in one view: chat on the left, a live preview on the right, and the file tree when you want it. You ask for changes in conversation, say “add a CSV export” or “restrict this to my team”, and watch the preview update. When it’s ready, you deploy it to a URL on your own instance and choose whether it’s private, shared, or visible across the workspace.
Lab apps run in the same disposable sandbox as skills, and their secrets live as references that resolve only at runtime. The idea is that a compliance analyst can ship a working internal tool in an afternoon without learning Git.
Deriv One also runs scheduled automations, flows that chain a person’s skills together, and workflows that pass work between agents with a human approval step.
What tells us it’s working is where people chose to use it. Almost every agent interaction at Deriv happens as an @mention in a shared team channel, in front of colleagues, rather than in a private chat. And the 221 skills behind those agents came from 54 people across the company, not one team guarding the gate.
Why we’re open-sourcing it #
A week after it shipped, I was driving home wondering how long we’d keep this edge to ourselves. Managed agents from the big AI providers already do pieces of what we built. As far as we can tell, none of them can yet reach into our internal systems, data, and business logic from outside our own security boundary. The day one of them can run inside our cloud, next to our identity systems and our data, some of that calculus changes.
Chris and Ansh disagree about which of the big providers gets there first, and Ansh thinks even the closest would still need a company like ours to add its own access control on top, which is what we’d already done for our own agents. JY’s answer is the one that stuck with me: stay ready to throw away the homegrown thing the moment something better shows up, because the pace of change is only going to speed up.
That instinct is also the real argument for open-sourcing it. Models and gateways will keep changing. Identity, secrets, skills review, sandboxing, and the slow work of getting capability to spread safely through a company change far more slowly, and that’s the layer that’s hard to build and worth sharing. Any company that can’t send its data to a third-party chat product runs into the wall we did, and regulated companies hit it hardest.
We built this because we had to, and there’s no good reason for every other team to rebuild it from scratch. There’s a selfish reason too: once other companies run it against directories and compliance regimes we’ve never tested, their fixes make the core better for us as well.
What’s in the open-source release, and what isn’t
The repository includes provider interfaces with local reference implementations, Docker images and compose files, Kubernetes starter manifests, and documentation for adopters.
It doesn’t include our production cloud plugins, our internal integrations, the Terraform and Helm configuration for our own infrastructure, our Slack DMZ relay implementation, or some internal-only Lab features. You bring your own model gateway, identity proxy, and cloud.
How to install and run Deriv One #
Clone the repository, run the setup wizard, and point it at any OpenAI-compatible gateway, including a local LM Studio or Ollama instance. Out of the box, you get:
- Workspace chat with model routing
- A skills registry with a publish and review flow
- Agent registration, with guided or manual Slack setup
- Lab, for describing, building, previewing, and deploying internal apps
- Sandboxed execution for skills and Lab runs
- SQLite for local development, and Postgres for multi-replica production
- Mock authentication for solo development, and OIDC for teams
git clone http://github.com/deriv-com/deriv-one-oss && cd platform
npm run setup -- --quick --test-gateway
npm run dev:stack
Deriv One is free to use under the MIT licence, and you don’t need a vendor account to try it. The adopter guide covers setup, identity, directory, and a production checklist. The cloud deployment guide covers architecture and managed services on GKE and EKS.
Questions you may have #
What is Deriv One?
Deriv One is an open-source, self-hosted AI platform built by Deriv. It gives a company governed AI skills, Slack agents, a multi-pane workspace, and a no-code app builder, all running on its own infrastructure.
Is Deriv One free?
Yes. It’s released under the MIT licence, and you don’t need a vendor account to run it.
Which AI models does Deriv One work with?
Any model behind an OpenAI-compatible gateway, including local models served through LM Studio or Ollama.
Does Deriv One work with Slack?
Yes. You can register agents as their own Slack apps, using guided or manual setup, and people @mention them in team channels.
Can I self-host Deriv One?
Yes; self-hosting is the only way to run it. The repository includes Docker images and compose files for local use, Kubernetes starter manifests, and a cloud deployment guide for GKE and EKS.
What we learned, and what’s next #
The lesson underneath all of this is the gap between what Rakshit asked for and what we built. A registry assumes the hard part is finding the skill. The hard part turned out to be deciding who gets to run it, and that reframe is why Deriv One is a platform today rather than a better-organised folder of GitHub links.
Part 2 looks at the governance underneath: how skills get reviewed and routed, how agents are registered and isolated, and how secrets stay out of the database. Part 3 covers what happened when a third of Deriv started using the platform, including what it took to get people sharing what they know.
If you’re building internal AI infrastructure, we’d like to hear where it breaks and what you’d need it to do.
Deriv One on GitHub · MIT licence · Security policy
Rotimi Akinyele is the Chief Technology Officer at Deriv.
Christopher Hernandez is a Security AI and SOC Team Lead at Deriv.
Ansh Choudhary is a Senior AI Engineer at Deriv.