Somewhere between the school run and a site visit, I notice something in one of our products that needs changing. I do not open a laptop, I do not log a ticket, I do not write it on my hand. I send a text message, the way you would to an engineer on your team. By the time I next look, the message has become a tracked task, the task has become written and tested code, and my phone is showing me screenshots of the result with an approve button waiting. This article explains the pipeline behind that, because the architecture is a preview of how a lot of work is about to flow, well beyond software.
Meet Ma'am
The engineer I text has a name. She is called Ma'am, after the way Bond addresses M in the 007 films, and she is my AI manager. She runs on her own server, I message her over iMessage like anyone else in my contacts, and she replies like anyone else in my contacts. The difference is what happens next: when a message is real work, Ma'am does not do it herself. She deploys agents to do it, briefs them properly, and reports back with the results. None of that is magic, and none of it worked on day one. It works because of the deep context I have already built into her back end: who I am, what our products are, how we operate, and what good looks like. The persona is fun. The context is the product.
The pipeline, step by step
- The message. Plain language, from my phone: what I noticed, what I want, any context worth adding. Voice notes work too, per the phone habit from earlier in the series
- The judgement layer. Ma'am reads it and decides what it is. Not every message becomes a task, some are questions it just answers, some need clarification it asks for. When it is real work, it writes the thing up properly as a tracked issue: clear title, description, acceptance criteria, better written than my text deserved
- The work. A Claude Code session picks up the issue, exactly as described in the overnight article: plan, build, test, iterate on the failures
- The receipts. The finished work arrives as a reviewable change with the agent's summary, test results, and screenshots of the change actually running, attached to the original issue so the whole story lives in one place
- The approval gate. Nothing merges without me. I review from wherever I am, approve or send it back with comments, and the agent handles the rest, including closing the loop on the original issue
Notice what I kept and what I gave away. I gave away the transcription of intent into process, the typing, the ticketing, the ceremony. I kept the two things that were ever actually mine: deciding what should change, and judging whether it did.
The design details that matter
Two choices make this work, and they generalise to any agentic system you ever commission. First, the intake agent has judgement, not a rule that every message spawns a task. Discretion at the front door is the difference between an assistant and a spam generator. Second, the human gate is structural, not optional, the approve step is built into the pipeline itself, per the guardrails principle from the agents article. Speed everywhere except the moment of commitment.
Why this is in a general series
Replace "code" in the pipeline with anything: a text becomes a drafted client proposal awaiting approval, a voice note becomes a scheduled social campaign awaiting approval, a forwarded email becomes a booked job awaiting approval. Message in, judgement layer, work performed, receipts attached, human gate. That five step shape is the template, and software is merely where I run it hottest. If you take one thing from this article, take the shape.
Video: from a text message to shipped software, end to end
Next: what happens when you point all this capability at a mate's very real, very unglamorous business problem.