AI interaction design
Most of my work is deciding what an AI system does, where it stops, and how a person stays in control of it. Two systems I designed and run, told through the interaction decisions behind them.
Case one · Production system I run
I run a multi-agent system on the Claude Agent SDK. The interesting part was never the code. It was the interaction architecture: how work gets classified, which model it goes to, when the system stops and asks a person, and how each agent knows its own voice and its own limits. That is the part I designed.
The conductor reads each task and sorts it before any work starts. Routine, well-scoped jobs go to a fast cheap model. Hard, self-contained jobs with a clear deliverable go to a deep-reasoning model. Short or unclear exchanges get handled inline instead of being handed off at all.
The escalation rules are explicit and written down, so the routing is predictable, not a coin flip. When a task sits on the fence, the rule is to default to the cheaper tier and only escalate when the work is clearly hard.
Reading, drafting, and planning run freely. But any action that touches the outside world, sending an email, deploying, publishing media, stops and waits. The agent drafts, a person approves, and only then does it proceed.
That gate is a design choice, not a safety bolt-on. It sets a clear line between what the system can do on its own and what a human signs off on, so the person stays in control of exactly the moments that matter.
I write the system prompts that define how each agent behaves: its tone, what it is allowed to touch, and, just as important, when it should stop. Stopping conditions are the part people forget. An agent that does not know when it is done keeps going and makes things worse.
The example below is one small, honest before-and-after: a plain-language intent I wanted, and the behavior the prompt produced.
Agents are confidently wrong in predictable ways, so I built adversarial review loops and check-skills that look for those specific blind spots before anything ships. The review is part of the system, not something I do by hand afterward.
I also built retrieval knowledge bases the agents query instead of re-reading raw files each time, which cut retrieval cost by roughly 50x and made the answers more consistent.
System prompt → behavior
"Behave like a lazy senior engineer. Write the least code that actually works, reuse what is already here, and stop at the first solution that holds."
· Checks for an existing helper before writing a new one
· Prefers one line over a new abstraction
· Stops at the first working solution instead of gold-plating
· Flags a corner it cut, and when to revisit it
Case two · Live client work
The Forbes Health operations dashboard is a custom tool for a private medical practice, covering billing, patient records, and ordering. The staff are not technical. The whole design problem was making a capable, partly-automated system feel safe and obvious to the people who run it every day.
An order cannot proceed without physician approval. That rule lives in the state machine, so the unsafe path simply does not exist in the interface. There is no warning to dismiss and no way to skip the step under pressure.
Designing the block and approve states as first-class parts of the flow means the guardrail holds on the busiest day, which is exactly when a warning banner would get ignored.
The staff are not engineers, so the interface is designed around their real competence, not an idealized power user. They now run the dashboard themselves and edit site content through an in-place visual CMS, instead of filing a request and waiting on me.
That was a deliberate goal: hand the day-to-day back to the people doing the work and take myself out of the loop for routine changes. It lowers the support load and gives them control.
Real operations software fails at the seams between systems. This one talks to a ModMed EHR, an InBody scanner, and ShipStation for fulfillment, and each of those is a place data can arrive late, malformed, or not at all.
The fulfillment path was verified live with staff running real orders, so the handoffs are proven in practice, not just on paper.
The database and the integrations are plumbing. What the practice actually experiences is the sequence of states: draft, approve, block, fulfill, and a content system they can drive without me.
Every one of those was an interaction decision about who is allowed to do what, when the system pauses, and how a non-technical person stays confident they are in control.