My spouse, Dr Souphi, is a phenomenal doctor who has always wanted to run her own clinic. I think she would be the first to admit that she is at her best as a medical professional, not a salesperson, clinic manager or financial controller.
But running your own business means doing all of those jobs. Too little of her time ends up being about what she does best: looking after patients and practising medicine.
As language models and coding assistants got smarter, I began to think I could help. For the first time, ideas I had carried around for years felt possible to build. I could create software to take on the administrative side of her business and let her focus on the patient and the medicine.
That was the plan. It has taken me three attempts to understand what it needed.
Summer 2024: a working website, an unfinished idea
My first attempt gave Souphi a functional website and a rudimentary system for patient management and invoicing. They were separate applications, but they did useful work.
Marketing was the part I never cracked.
We had photographs from patients who had consented to their use. How could I turn those into compelling before-and-after images for social media? How could the software help tell the story of her work?
In 2024, that felt out of reach to me. Looking back at that code now, I can still see marketing features connected to placeholder services. I had outlined a solution without making the whole thing work.
I left her with something good enough to use. It was a long way from the business support I had imagined.
2024 · Separate foundations
Spring 2025: surely the stack was the problem
The models had improved. This time, I was sure I could get it right.
I was half convinced that my first design was holding me back. I had one app for the public website and another for administration. I wanted to bring the journey together: from someone discovering Souphi on social media to becoming a paying patient.
I built a new admin application, souphi-admin. It and the public site
remained separate applications.
Sharing a D1 database meant they could work with the same data. That felt like
a way to connect the journey without having to make everything one app.
I was no longer hand-crafting every piece of code with autocomplete helping along the way. I could describe what I wanted and have the model build whole components. I started again, with bigger ambitions and much faster progress.
2025 · A shared data layer
Early 2026: faster code was not enough
By the start of 2026, I had to admit that I had failed again.
The code had drifted. I was going round in circles, reimplementing features I thought I had already built. In my judgement, the codebase was no longer worth rescuing.
It was not just Souphi’s software. I had more than a dozen repositories for various half-finished projects. GitHub’s bots seemed to chase me daily about vulnerable packages and ageing dependencies.
I had become much faster at generating code. I had not yet found a reliable way to keep it coherent.
The third attempt started with a new monorepo: one home for my projects and their shared code. There was a new stack too, built around Cloudflare Workers and Convex.
The more important change was how I worked. The coding agents had clear boundaries and instructions. Automated checks enforced the design principles. Tests and review were part of the work, not something I hoped to come back to.
For the first time, I felt I had the codebase under control. I would say I had finally got that part right.
2026 · Shared code, enforced rules
The models now had APIs that made the marketing work feel achievable too. I could connect writing, images, narration and video generation to real software, rather than move everything between separate tools by hand.
By September 2026, I could claim partial success. The codebase was in better shape. But my approach to marketing had exposed a different problem.
A month to automate what I could help create in two hours
First, I co-created a treatment explainer episode with Codex. It took a couple of hours at most.
Then I spent a month building a system to automate the creation of twenty episodes.
To make the series repeatable, I broke production into 23 steps.
First came research: supporting articles, source quality and clear limits on what we could say. Then the script and narration, so we could hear the pacing. Then the scenes: introduce the patient and concern, show an unsuitable treatment, explain the anatomy, explore a more holistic approach and its limits, and recap. Finally, assemble the video for review. Publication still needed approval.
Each scene had its own work. Create the image. Bring it to life. Hold it long enough to make sense. Move to the next scene. Fit it to the narration.
Research and writing needed different tools from images, motion and speech. The system needed to track dependencies between steps, preserve results and recover from failures. I built different agent roles, provider connections, retry handling and a graph of the work.
These were real engineering problems. The automated system needed answers before I could leave it running. In a workbench, I would still need safe handling of paid requests, but I could make more of the creative spending decisions myself.
My rough estimate is that the automated approach involved 50,000–100,000 lines of code. I believe a focused workbench could have needed 10,000 or fewer. That is my estimate, not a measured comparison with a finished alternative.
The two hours went into making an episode. The month went into building a production system. I had made a format repeatable before knowing whether the audience would respond to it.
Changing that format now meant changing the machinery behind it. The return I needed was a faster way to learn what worked for Souphi’s audience. I had built a faster way to repeat my first answer.
The light bulb moment
Alongside that work, I had been using tools that showed me a different approach.
I used Claude Design to help me make much more compelling public websites. More recently, I turned to Codex Security as I became more concerned about what increasingly capable models meant for cybersecurity.
Claude Design lets you develop visual work through conversation, comments, direct edits and controls. Codex Security investigates a codebase, validates possible findings and proposes fixes for review.
They serve different purposes. What I see in both is a place built around the work, with an agent helping me do it. I can inspect what is happening and shape the result. Codex and Claude Code had already taught me the value of that in development.
Google’s The New SDLC With Vibe Coding puts a name to the surrounding machinery: the harness. It describes instructions, tools, execution environments, orchestration, guardrails and ways to observe the work. The model is only one part of the system.
I was also exploring Open Design and DeepSeek Harness. They reinforced a lesson I had already learned in development and failed to apply to marketing.
In development, I had moved beyond expecting a good prompt to produce the finished result. Yet when I tackled marketing, I went straight back to that expectation. Write enough specification. Provide enough context. Add agents. Somehow make the whole thing run.
I was treating AI like a conventional program: input, process, output. I needed an assistant that could share the work.
But creative work often changes as you do it. You hear a script and realise it drags. You see a scene and want to take it somewhere else. You publish something and learn which questions the audience actually cares about.
The work needed a place where those decisions could happen as it took shape.
That is what I mean by a workbench: a place to keep the developing work, inspect it and direct the next change. Its harness gives the agent the instructions, context, tools and controls to help.
A better place to make an episode
Imagine having the sources, script, scenes and narration together. I could ask the assistant to shorten a section, try another image or compare two versions. I could see what changed and decide what to keep.
The difference would not just be adding a screen or an approval button. I already had those. It would be making exploration and revision the normal way to work, without having to encode every variation in the production process.
Useful parts would still run automatically. Research could be prepared. An approved scene could be generated. An edit could be assembled. Medical review would still matter.
I could decide whether another attempt was worth paying for. The system would still need to avoid duplicate charges and respect limits; it would not need to make every creative spending decision on my behalf.
I believe it would have taken less effort to build. It could also have reduced those two hours of work. More importantly, I could have learned from each episode and changed the next one to suit the audience.
That is the workbench I now wish I had built. It is not an alternative I have already tested.
Why Drawloom?
I now believe purpose-built workbenches, powered by agent harnesses, are the right starting point for complex, creative business work.
Marketing is one example. The same question applies to the other jobs around Souphi’s practice: where would a capable assistant, with the right tools and controls, give her time back?
We do not need to build every part from scratch.
Codex App Server exposes Codex to product clients, including conversation history, approvals and live events. Claude Agent SDK provides the agent loop, tools and context management behind Claude Code as a programming library. These are distinct integration offerings, not interchangeable APIs.
They give us something substantial to build on. They do not supply the business workbench, or decide how its knowledge, tools and controls should fit together.
That is why I am building Drawloom: reusable infrastructure for those workbenches. Each product keeps its own interface, business rules and way of working. Drawloom provides shared capabilities for context, execution, tools and controls, so each product does not have to build them again.
The boundaries matter. A provider can manage its agent’s conversation without owning the business’s memory. Asking for a tool is not permission to use it. Granting permission is not the same as enforcing limits on the machine where it runs. Drawloom keeps those responsibilities separate and replaceable.
Drawloom · Shared foundations, distinct responsibilities
Read the diagram
The workbench owns the interface and business rules. The application chooses independently replaceable implementations of Drawloom's capabilities.
- Orchestration coordinates runs, steps and child work.
- Memory retains experience for future retrieval.
- Knowledge holds sources and claims with provenance.
- Context compilation prepares input from memory, knowledge, instructions, policy and the task.
- Agent execution provides interactive sessions; the provider keeps its inner agent loop and transcript, distinct from Drawloom memory.
- Model inference handles bounded model requests. It does not represent an agent loop.
- Policy and approval decide whether an action is allowed.
- Tools validate and perform the allowed invocation.
- Sandbox enforces filesystem, process, network and resource limits.
- Observability records execution evidence from all capabilities, not only tools.
- Evaluation assesses executions and artifacts against declared criteria.
Return paths and many cross-capability relationships are omitted. Sources: ADR 0005, ADR 0007 and ADR 0008.
Drawloom is early. The boundaries are taking shape, and the work still needs to prove itself in real use. I want it to be approachable for a small business, with useful local or free-tier options wherever possible.
I have no wish to build a fourth elaborate system that misses the point.
The reason for all of this is still the same as it was in 2024: give Souphi more time to be a doctor.