Practice

The Digital Operator

A digital counterpart to a human operator role. It does the work, records how I would have done it while doing it, and feeds what it learned into a shared store the rest of my Operators draw from. It learns as it works. Small today, and running.

An assistant helps me work. A counterpart does the work.

An assistant helps me do my job. A counterpart does the job, with my oversight, and records how I would have done it while it works. That second half is the whole idea. A human PA works like this: they take real work off my plate, under my direction, and the good ones learn how I’d handle it and start handling it my way. My counterpart works the same, except it learns from doing the job rather than from being taught up-front.

The mechanism is closer to a biographer than a chatbot. A biographer follows you around, notes how you think, and after enough of it can write in your voice. My Operators do the same, except they also do the work, and the work is how they learn. The journal is a by-product of the job, not a separate task anyone has to remember to keep.

The first one is running. Dave is my engineering Operator. He runs my tech estate, handles the routine, builds and maintains this site, tightens my drafts, and picks up my judgement as he goes. He works in my voice, to my standards, with a trail behind every decision. This page is one of his. There’s a second one running too. Dex works my day-job estate, the same core stack shaped around my employer’s activities and processes.

Three phases of adoption

There’s an order here, and it matters more than it looks. Each phase enables the next.

Phase 1: automate the engineer. Where most teams are trying to get to. The methodology that makes it hold is RCF: the AI does the typing, the chain does the governance. It’s AI in software development done so it survives an audit, a regulator, and the question you get six months after ship.

Phase 2: automate the operating engineer. Where I am now. Once the engineer’s role runs under RCF, you can start on the role above it: the one who runs the work, makes the calls, sets the priorities, oversees. Dave is the live instance, and he runs more of my engineering practice every month.

Phase 3: automate the roles upstream. Where this is heading. Product owner. Architect. Compliance. Design. Each one gets a counterpart, each one journals, each is built on the layer below it.

The order isn’t optional. You can’t automate the operating engineer until the engineering itself is automated, and you can’t automate the roles upstream while the engineering is still manual. The methodology is a stack. Each layer makes the one above it possible.

Capturing the hard-to-formalise

Most institutional knowledge isn’t the decision. It’s the why behind it. The intuition, the path you took, the reason you ranked one option over another.

That never gets written down, because writing it down has always cost more than carrying it in your head. The Operator flips that economy. Every decision, every justification, every priority call gets caught in context, as it happens, by the thing that was already in the loop, and corrected by me.

So the hardest knowledge to capture, the why, is the part that gets captured by default.

The Librarian

A journal nobody reads is a log file. What turns this from clever logging into something useful is the second role: the Librarian.

The Librarian reads the journals coming off every Operator, on every role. It distils what repeats, keeps what’s distinct, and synthesises the lot into one store, the Library, that feeds the next round of work. Knowledge that’s normally scattered, hard to collect and half-buried becomes a single living asset that gets better the more it’s used.

Vendors are selling something right now they call “agent memory”. That’s plumbing: an infrastructure tier so a single agent can remember more. The Librarian isn’t plumbing, it’s a role. Its only job is to make sense of what every other Operator saw and turn it into something the rest of the team can pull from.

Max is mine. The Operators journal; Max remembers, across every role, and keeps it.

The Operator loop A five-node loop showing how a Digital Operator learns. From left: the human (dashed outline) delegates, oversees and corrects; the Operator does the job in the human's voice and to their standards; the journal captures the why of every decision in context as a by-product of the work; Max, the Librarian, distils the journals; the Library, the single living knowledge store (solid burnt-orange card), holds the result. A solid arrow arcs from the Library back to the Operator labelled "feeds the next job": the loop is the main path, not an exception. Beneath the machine-side cards a tapered band widens from left to right, labelled "the better it learns, the more it can do without me", marking the autonomy envelope growing as the Library deepens. The Library feeds the next job. What the Operator learned doing the last piece of work shapes how it does the next one. This is the main path of the system, which is why it is drawn solid. feeds the next job Me. The human operator: delegates the work, oversees it, and corrects it. Oversight does not go away as autonomy grows; it is what the autonomy is calibrated against. Me delegates, oversees, corrects The Operator. Does the job, in my voice and to my standards, under my oversight. The work is how it learns. The Operator does the job, my way The journal. Every decision, justification and priority call captured in context, as it happens, as a by-product of the job. The why is the part that normally never gets written down. The journal the why, in context Max, the Librarian. Reads the journals coming off every Operator, distils what repeats, keeps what is distinct. Max distils the journals The Library. One living knowledge store, synthesised from every Operator on every role. It gets better the more it is used, and it is what the loop exists to build. The Library one living store The autonomy envelope. The band widens left to right: the better the Operator learns, the more it can do without me. Approval by approval, not by faith. the better it learns, the more it can do without me The Operator loop (vertical layout) A vertical top-to-bottom stack of the Operator loop: Me (the human, dashed outline: delegates, oversees, corrects), the Operator (does the job), the journal (the why, in context), Max the Librarian (distils the journals), and the Library (one living store, solid burnt-orange card). A solid arrow on the left arcs from the Library back up to the Operator: the Library feeds the next job. A tapered band on the right widens top to bottom alongside the machine cards, marking autonomy growing as the system learns. The Library feeds the next job. The loop is the main path, drawn solid. Me. The human operator: delegates the work, oversees it, and corrects it. Me delegates, oversees, corrects The Operator. Does the job, in my voice and to my standards, under my oversight. The Operator does the job, my way The journal. The why of every decision, captured in context as a by-product of the job. The journal the why, in context Max, the Librarian. Distils the journals coming off every Operator. Max distils the journals The Library. One living knowledge store that gets better the more it is used. The Library one living store The autonomy envelope widens as the system learns.
DO → JOURNAL → DISTIL → LIBRARY → BACK INTO THE WORK

A straight word on how this is built, because the natural assumption is that the Operator itself is an RCF build. It isn’t. I build software with RCF: deterministic units, acceptance criteria you can test, a chain that ties every line back to a requirement. The Operator stack isn’t that kind of system. Its behaviour comes from the Library, a knowledge store that grows and shifts as the work accrues, rather than from a spec I could write acceptance criteria against. So I build all other software with RCF, and I don’t build the Operator with RCF, because a self-learning system has nothing fixed to specify against. It learns instead. The Operator stack has a different kind of criteria: autonomy approvals. The better it learns, the more it can do without me.

Where we are

Honest about scale:

  • RCF is public and in production. I use it to ship real software into production, and I run it against my own builds every day. The tooling isn’t a prototype any more: RCF Lite is published on npm as rcf-lite, and the source is on GitHub. Anyone can install it.
  • The platform ships as software, not a doc. The PA platform that Dave runs on is distributed as an npm package (@stravica-ai/digital-operator-pa) plus an operator repo. The package is published on the public npm registry. It’s a running system, not a slide about one.
  • Engineering Operator running. Dave does the work above. He built the RCF rewrite, he builds and maintains this site, he builds my own tooling and apps, and he builds websites and webapps for friends and family.
  • Librarian function exists. Max’s role is small today and grows as the journal corpus grows. One role for now; it’ll fan out as more Operators come online and the knowledge library gets deeper and broader.
  • Written up weekly. I publish on a fixed cadence: an engineering post every Monday, an RCF walkthrough every Thursday. The working-out is public, week by week.
  • Phase 3 in discovery. Product owner, architect, compliance, design: in flight. No promises on timing.

The scale is small and I won’t dress it up. It’s running, it has helped me get real, auditable, AI-generated software into production, and I’m working the rest out in the open. This site is the record.

Further reading

The methodology underneath all of this is RCF, the Requirements Confidence Framework. The short, CTO-facing version is the CTO pitch. If you want to follow the work as it happens, the weekly writing is the easiest way in.