Three problems. Three systems.

When a scale-up brings me in, the first thing I want to know is what is actually broken today. Discovery in week one usually surfaces three patterns. I have already built the systems that solve each one.

Problem one. Data without answers.

Most scale-ups sit on years of customer conversations, internal docs, decisions and notes. The information is there, the recall is broken. AI tools get plugged in and hit the same wall because the underlying retrieval is naive and the context layer is missing.

What I built. Open Brain. A semantic memory layer between any AI tool and a structured knowledge graph. Task-aware retrieval, structured taxonomy, MCP and REST endpoints. Built on MCP in January 2026, before the protocol was widely adopted.

Translated. A semantic layer over your existing sources (Notion, Slack, Drive, CRM, internal wiki). Tools change, the layer stays. Governance and audit designed in from day one.

Problem two. Tools that do not talk.

Every scale-up has the same backend stack. CRM, comms, docs, billing, a few cloud functions held together by hope. Data flows manually, handoffs leak, AI gets bolted onto one tool and creates a fifth silo.

What I built. Mono Dash. An agent orchestration platform that coordinates multi-agent workflows across Notion, Google Drive, Telegram, Gmail, Moneybird and Make.com. Routing, state, escalation, approval gates. Each agent owns one part of a flow.

Translated. An orchestration layer over your existing tools, with agents owning specific flows end to end. Each agent role researched before assignment, and a model and safeguard chosen to fit the role. No new vendor, no rip-and-replace, just the connective tissue you do not yet have.

Problem three. Volume outpacing the team.

Customer requests come in faster than the team can answer. Hiring is slow, cost per request climbs. Leadership asks for "an AI chatbot" and gets a thin wrapper around GPT that hallucinates pricing and routes nothing useful.

What I built. The Memortium service bot. Customers upload a photo, the bot evaluates it, answers questions, gives delivery estimates, takes orders directly in the conversation. The order routes into the same back-end pipeline that handles email orders. The bot is a doorway into the existing flow, not a wrapper around a model.

Translated. A customer-facing AI product that handles inquiries, qualifies leads, takes orders, and routes everything into your back-end. Volume can grow without the team growing at the same pace. Token-aware routing keeps cost per conversation in line with value.

The pattern across all three is the same. The system is designed around a specific flow that was broken in a specific way. I look at how an order moves through your company today, then I build what fixes the part that is broken. The systems get used because they are built around the work, not added on top of it.

Speed is possible because the design work happens up front. Open Brain went from idea to working version in two days. Mono Dash was a weekend prototype that became a platform. The service bot took less than a week because the back-end was already there. The tech debt that worries CTOs gets prevented at the design stage, not patched in production.

The human side

Three systems, and none of them is really about the technology. Each one answers a question someone in the organisation was already asking.

Open Brain exists because people lose answers they once had. The memory layer works precisely because nobody has to feed it: it sits underneath the tools people already use and gives back what the organisation already knew. Adoption is not a phase here, it is the absence of one.

Mono Dash keeps people in the chair where it matters. Agents own their flows, but every escalation path ends at a person, and the approval gates are designed before an agent gets its role. Autonomy is granted per task, never assumed.

The service bot faces customers who do not care that it is AI. They want an answer about a photo, a price, a delivery date. The bot gets held to the same standard as a colleague: it helps faster, or it is in the way. It is designed for that standard, not for the demo.

And all three are built to be handed over. Solo-built, but documented, bounded and orchestrated so a team can run them without me in the room. A capability that only works with its builder next to it is not a capability, it is a dependency.