My AI, at work.

How it is built.

Every message takes the same path. An employee asks in plain words. An orchestrator works out who is asking, what they are allowed to see, and what they want, then hands the turn to one of five agents. That agent does the job with Claude and the company systems, and the guardrails stay on the whole time.

The orchestrator decides cheaply first. If a draft or a decision is waiting, "yes" and "cancel" belong to it. Then a short list of readable rules covers the phrasings the demo knows. Only when no rule matches does a small, fast model label the message, and if it is unsure the message goes to policy search, the one path that can only read. The decision and its reason are the first line of the trace under every answer.

Five agents, each with only its own tools:

Each use case below has its own chapter. If you are here to decide rather than to read, start with the business case.

Build the working version yourself, then hand it over.

Each chapter has its own lessons. These held across all of them, and they are the reasons behind the decisions you can see on this page.

1. I wrote the promise before the code, and the promise was fiction for a week.

   This page said the assistant recognized a harassment report and handed it to a person. Nothing in the code did that. I caught it building a table where every guardrail has to name the test that proves it, and there was no test to name. Writing the claim first is useful, because it shows you what is missing. But a claim on a page is a promise, and it ends one of two ways. I built it: a rule that stops before retrieval, names the ethics line and the EAP, offers a person, and writes no ticket and no record of what was said. Why it matters: in a real deployment that gap is not a copy error. It is someone’s account of being harassed sitting in a ticket table that IT support can read, found later by the wrong person. The demo you show and the system you ship have to be the same thing, or the demo is just a story about software.

2. Sixty-seven tests were green and it was still wrong.

   Twice in one day. The stop rule missed “I want to report a safety concern,” because it matched the word harassment rather than the meaning. Then it read “How do I submit an expense report?” as a yes and opened a chat with HR, because the confirm check matched the word submit anywhere in a sentence. Neither appeared in the suite. Both appeared within thirty seconds of typing into the demo. Evals prove the cases you thought of. Using the thing finds the ones you did not, and then those become cases, which is how the suite got to sixty seven. Why it matters: a green suite is a floor, not a warranty. A team that ships on green alone finds its gaps the way I found mine, except in production, with someone’s pay or privacy attached, and with a customer reading the transcript back to them.

3. The build time collapsed. The spec still matters.

   I started at the code on purpose. I wanted to experiment, so I began with prompts and built the working version as I went, deciding the rules on the fly as each use case took shape: which writes are irreversible, what a contractor hears when they ask about parental leave, who may approve what. Then I wrote the spec from what I had built, and the spec was where those rules became visible as product decisions instead of lines of code. In the old days a spec was the norm, and the document was how you made sure your own thinking was clear before anyone built. The principle has not changed; the order I learned it in has. Prompt and build to learn, then turn what the prompts taught you into the spec, because even when a model does the building, the clarity has to come from somewhere. The next use case starts from the spec.

4. The rough cut is mine now. Marketing gets a working version to polish.

   The walkthrough video above would have been a request to marketing and a place in a queue. I made it in an afternoon, from stills and a script. The free voice on my Mac sounded like a machine. ElevenLabs did the job until its free tier ran out mid-project, and Gemini finished it for a few cents. Swapping the voice was one flag, because the narration, the frames and the assembly are a script rather than a file somebody exported. The lesson is not about voices. For something this size I can build the version that works, and the cycles a marketing team spends on a first draft go to polishing a thing that already exists.

5. A running prototype is how you find out what a team would need.

   The same holds for the agents. With a prototype running I can try what a small team building this for real would have to have: which tools, which gates, where the traces go, what the evals must catch. I am finding that out now, on a working system, instead of writing it into a plan and hoping.

6. Build the conversation first. Hook it up later.

   The first version was the conversation flows and the use cases on one surface, connected to nothing. Then the search behind it, then a real identity source in Google Drive. The next passes stand in for the systems an enterprise already runs, a ticketing system, a work tracker, team chat, to prove the connectors one at a time. Each pass makes it less of a demo and more of a working version.

7. There are two ways to stop the assistant from doing something it should not. I used the second.

   The first is to tell the model in its instructions: do not describe documents this employee is not allowed to see. That is a prompt. The model usually obeys, but not always. A clever question, a long conversation, or a bad day for the model, and it can slip. You cannot prove it will never happen. The second is to make the forbidden thing impossible. Before the search even runs, the code removes every document Alex is not allowed to see. The model never receives them. It cannot describe the executive pay bands because they were never in front of it. The demo does this for every rule that matters. A time-off request is only written to the HR system if the code sees a yes in the latest message; the model cannot submit on its own. A manager's approval only goes through if the code confirms that person is the employee's manager; the model saying "Jordan approved" does nothing by itself. The prompt still carries those instructions too, but as a backup, not as the thing I rely on. Advice is something the model can choose to ignore. A rule is something it cannot get around.

8. The fourth use case started from the spec. The front door was already built.

   Get help is the first use case I wrote before I built. Three flows as transcripts: try the article, then the ticket; the support agent sees the pattern and publishes the fix; a person in the same thread. The build reused what the first three had left behind: the orchestrator, the access rule that removes documents before the model sees them, the yes gate on every write, the trace under every reply, and the eval runner. The new work was the three flows, the seed tickets, and the two screens. The same gate that protects a time-off request protects a ticket, an article, and a suggested reply to a support agent. Twelve new cases took the suite from 46 to 58; the stop rule later took it to 67.