2025 · SaaS · Lead · Dev13 Systems
Dev13 Systems — an AI team that knows the business
An AI-native operating system for agencies: CRM, projects, HR, finance and knowledge in one platform, with 25+ specialist agents that draft the work and people who approve it.
8 modules and 25+ specialist agents in production, every output approved by a person
Context
An agency runs on a stack of disconnected tools — CRM here, projects there, HR and finance somewhere else — and the coordination between them is manual work nobody is paid for. The AI products sold into that gap have their own problem: they charge per seat on top of a subscription the team already pays for, they keep the customer's data in yet another silo, and they answer everything shallowly from one generic assistant.
The brief was the opposite of a chatbot bolted onto a CRM: one platform covering what an agency actually runs on, with a roster of specialist agents working from the organisation's own knowledge, and a human in the approval path for anything that leaves the building.
Decisions
Chose Bring your own Claude subscription — the customer's key, the customer's plan over reselling tokens with a per-seat AI markup
Agencies already pay for Claude. Reselling the same intelligence back to them adds a margin they can see on their invoice, ties the product's price to one vendor's, and makes switching models a commercial decision instead of a technical one. Charging for the platform and letting the customer bring the model removes all three.
Chose Exposing the platform to agents over MCP, inside the Claude client the team already uses over building a proprietary chat interface into the product
A new chat UI is another tool to learn and another place the customer's data gets copied. Connecting once and running any agent by name where people already work meant the platform had to expose good tools rather than a good chat window — which is the part that actually compounds.
Chose Agents draft, a person approves, every write attributed to that person over letting agents act autonomously with a review queue after the fact
An agency's output carries professional liability. Anything that can be sent, saved or acted on has to have a person's name against it, and an approval step after the damage is not an approval step. It costs a click per action and buys an audit trail that survives a client dispute.
Chose Tenant isolation at the database level, with retrieval scoped inside that boundary over filtering by organisation in application code
Retrieval that crosses a tenant boundary is not a bug, it is a breach — one agency's knowledge base answering another agency's question. Application-level filters are one forgotten `WHERE` clause away from that; putting the boundary in the data model means the mistake cannot compile.
What I did
I architected and built the platform end to end — eight modules (CRM, projects, people, finance, learning, knowledge base, the AI team and a leadership command centre) on one tenant-isolated data model, with role-based access governing the application and the agents alike.
The AI layer is 25+ role-specific agents, each with a real operating playbook, reached over MCP servers I built that expose the platform's tools to whichever Claude client the team already uses. Underneath sits the retrieval and evaluation layer that every AI project here reuses: hybrid search over pgvector and Qdrant with reranking, layout-aware chunking, Langfuse and LangSmith tracing, LLM-as-judge regression tests against golden datasets, and per-tenant token and cost tracking.
Outcome
Twenty-five-plus specialist agents run in production across eight modules. Every agent output is a draft until a person reviews and approves it, and every write is logged and attributed to that person — so the judgement and the accountability stay human while the typing does not.
Because agents run on the customer's own Claude subscription, there is no per-seat AI markup and no model lock-in: the intelligence is whatever they already pay for.
In hindsight
The evaluation layer — golden datasets, LLM-as-judge regression tests, tracing — was built after the first agents were already in production, and that order was backwards. Until it existed, every prompt change was an argument about whether output had got better; afterwards it was a number. On the next agent system I would build the harness before the second agent, not after the tenth: it is cheap early, and it is the only thing that makes iteration honest.