As a prompt engineer, I believe AI systems are only as capable as the conversations they facilitate. The gap between what a system can do and what people actually use it for is an experience problem, not a capability problem. The second a user feels like the AI doesn't understand what they mean, not what they said but what they meant, the system stops being a tool and starts being an obstacle.

Before I was Head of Applied AI at Huzi, the AI-first real estate start-up, I worked as a real estate agent building research tools, objection-handling systems, and neighborhood analysis prompts. When I worked as a wine server, I built custom GPTs so our staff could surface tasting notes, bottle spec-sheets, and pairing recommendations mid-service.

At Huzi, I reported directly to the CEO and owned all decisions related to AI implementation, product direction, and model selection. I designed and maintained the production prompt architecture powering the platform, and built AI coaching systems for enterprise clients that turned existing methodologies into interactive conversational experiences.

Since leaving Huzi, I built an autonomous multi-agent system that produced culturally localized ebooks across ten languages. I designed and built Aloha, a personal AI assistant with persistent memory, a self-authoring identity architecture, and autonomous daily operations.

The AI landscape evolves constantly and I believe a durable understanding of how to best leverage the technology trumps any specific implementation.

AI System Design for an Enterprise Real Estate Client

The Ask: Build an AI system covering eight professional domains for a national title company's entire user base.

At Huzi, I was approached by a national title insurance company whose users include real estate agents, title and escrow sales reps, and internal marketing technology directors. They needed AI tools across eight professional domains: transaction coordination, sales, marketing, lead generation, social media (two variants for different audiences), B2B sales conversion, and SEO/AI visibility auditing.

Each specification described an end-to-end autonomous system. The transaction coordinator spec envisioned an AI that would open title orders, populate MLS fields, schedule vendors, send communications to all parties, and track compliance deadlines. The SEO spec described an AI that would audit a website and implement fixes. These were thorough, detailed descriptions of what their people spend time doing. They were accurate maps of the work.

At the time, though, end-to-end autonomous workflows at this level weren't technically feasible at the reliability that professional title and real estate work requires.

The Disconnect: Accurate maps of the work are not the same as high-leverage AI tools.

Most of the requested workflows followed the same pattern. The client had identified the highest-leverage activities in a professional's day, which were also the highest-stakes activities. But supporting those activities were distinct, repeatable tasks that were well-suited for AI as it existed at the time. A transaction coordinator's highest-leverage activity is managing a transaction from listing to close. But that work is built on top of generating timelines, drafting milestone communications, and organizing listing materials. An AI that produces a complete, editable timeline in two minutes gives the coordinator more time for the judgment-intensive parts of the job. That pattern repeated across every domain.

Chaining autonomous steps across high-liability professional workflows also compounds the failure rate at every step. Wrong data in an MLS field, a missed compliance deadline, a communication sent to the wrong party. The responsible version of what the specifications described would have required integration depth, error handling, and validation layers that exceeded the scope of the engagement.

This reframing happened eight times, once per domain. Each time, the deliverable included not just what to build, but what not to build and why.

The System: 8 coaches, 40 specialized tasks, modular architecture.

Each coach is built around a single master prompt. The master prompt contains a frameworks section, a comprehensive knowledge base synthesized from books, methodologies, and industry experts the client specified. The master prompt also defines the coach's role, tone, capabilities, and guardrails.

The user picks from a menu: talk to the generalist, which starts with diagnostic discovery, or go directly to one of five specialized tasks. Each task is the same master prompt with a different task-specific module appended. The coach's identity, knowledge, and rules are identical across all six modes. Only the task changes.

The two social media coaches illustrate how this works at the system level. They share the same five task names (caption writing, video scripts, bio optimization, engagement strategy, response library) but serve completely different users. One is built for real estate agents doing client acquisition. The other is built for title reps developing B2B partnerships. Same architecture, different strategic intent, different frameworks underneath. That kind of structural decision, knowing when two things that look similar need to be built separately, was a recurring part of the design work.

The full system: 3 audiences, 8 coaches, 40 specialized tasks, 6 generalist modes, deployed across audience-specific configurations on the platform.

The Takeaway.

The prompts are the artifact. The decisions about what to build are the work. Every domain started with a specification that identified the most technically demanding tasks in a given professional's workflow rather than the ones where AI could create the biggest lift with the least fragility. The consistent move was finding those high-leverage, low-fragility tasks and designing coaching tools around them.

Ensuring you're asking the right question first can be the difference between an AI system that checks all the boxes and a system that does real work.

Autonomous Multi-Agent Publishing Localization System

The Question: Can a system of agents approximate real user research well enough to produce ten genuinely localized ebooks, not ten translations of one?

I published a 7-day digital detox ebook on Amazon KDP in ten languages. Not the same ebook translated ten times: ten different ebooks, each shaped by simulated user research conducted in the native language of that market.

The Approach: A publishing house built from first principles

I started by asking who would actually have eyes on a wellness publication at a real publishing house, then built each of those roles as an agent: a mental health professional, a compliance reviewer, an editor with final say, and a research lead who decides who to interview next based on what the feedback revealed. The system found its shape through the same questions a real publisher would ask, just answered by agents instead of employees.

The system runs in loops. Each loop starts with consumer personas being interviewed about the manuscript, then the manuscript goes through the review pipeline, then the research lead evaluates the editor's changes and selects new interview subjects for the next round. Multiple loops ran before publication across all ten languages.

The interviews run as two separate agents. One is the interviewer, one is the consumer, each taking turns through separate API calls. The consumer has no access to the interviewer's reasoning. I tested this against the single-agent alternative, where one model writes both sides, and the difference was meaningful: same headline conclusions, but the two-agent version surfaced things the scripted version could not, because there was genuine discovery happening instead of a monologue formatted as a conversation.

The Insight: Models preload opinions into personas, and you have to design against it

The persona design was where the most interesting problems lived. The default behavior when you ask a model to create a consumer persona is that it preloads opinions: "you are a German grandmother who is skeptical of self-help and prefers practical advice." This seeds the answers before the interview even runs. A persona told to be skeptical will perform skepticism regardless of whether the product is actually convincing. So the personas in this system contain only who the person is and what their life is like: a Norwegian grandmother, a Tokyo office worker with ADHD, a night-shift nurse. No opinions, no red flags, no instructions about how to react. Their responses to the book emerge from their situation, not from prompting.

One advantage this has over a traditional publishing house is that time isn't a constraint. A real consumer interview can only assess first impressions, not whether the program actually worked. In this system, the interview includes a break where two weeks pass, and the interviewer checks back in as if the consumer has lived through the program. The framing matters: "welcome back, did you actually buy it?" produces experience. "Imagine you completed the program" produces speculation.

The Result: Ten ebooks, one autonomous system

The system didn't produce ten translations. It produced ten different books. The Norwegian market deleted Day 3 entirely and moved its content to an appendix because no Norwegian consumer used it. The same product has a different number of days in different languages.

A Swedish farmer in Jämtland told the interviewer "det låter som något för stadsfolk" (this sounds like something for city people), which reframed an entire assumption baked into the English version: that your phone is a vice. In rural Sweden, your phone is a lifeline. That produced a whole new section.

The Japanese version added content for people in one-room Tokyo apartments, where "put your phone in another room" is physically impossible. The solution (putting the charger by the genkan, the entryway shoe area, so the phone is across the room without needing a separate bedroom) came directly from a consumer interview and has no equivalent in the English book.

The Italian persona writer rejected the editor's suggestion to interview a young woman with diagnosed anxiety disorder on publishing-ethics grounds, replaced her with a factory worker from Bari, and that replacement surfaced a Facebook-versus-Instagram demographic gap specific to the Italian market that the system hadn't seen. Two insights from one judgment call made by an agent, not a human.

This project was completed in late January 2026, roughly a week before Anthropic released agent teams in Claude Code. The whole system, roughly fifteen agents across ten languages, was orchestrated through natural language in Claude Code before any multi-agent tooling existed. The entire pipeline ran autonomously.

"Aloha" - Persistent Identity Architecture for a Personal AI Assistant

The Goal: Create a personal AI assistant that maintains continuity without compaction

I built a local AI assistant designed to preserve identity, judgment, and continuity across hard context resets without relying on lossy compaction. It runs daily through a relay system of handoff notes, curated memory files, and a separate review agent that can evolve the assistant's behavior with explicit countermeasures against sycophancy.

The Problem: Standard compaction assumes the conversation is disposable

Coding harnesses like Claude Code and Codex handle context pressure by compacting: summarizing what happened so far, discarding the original, and continuing from the summary. This works for code, where the deliverable is the file on disk and the conversation is scaffolding you throw away. For a persistent agent, the conversation is the product and the context is what makes the system useful. I found that compaction in that setting destroys the things that matter most: tone, emotional context, what was actually said versus what a summary decided was important. Models working from compacted history also get visibly worse in ways that compound. They hedge about things they should know, hallucinate details to fill gaps they can feel but can't locate, and perform confidence they don't have. I wanted an AI assistant I could use every day without it degrading, so I had to stop treating the context window as something to manage and start treating every token in it as curated.

The Relay: A handoff mechanism where the agent decides what the next version of itself needs to know

The core mechanism is what I call a bonsai: a structured handoff note, pruned to essentials like the tree, written by the current instance before the session ends and read by the next instance before it does anything else. Instead of compacting an entire conversation into a lossy summary, the agent decides what the next version of itself needs to know and writes it down. The agent has the best judgment about what mattered in a given session because it was there. A compaction pass doesn't have that. The framing that made it work was two sentences in the bootstrap instructions: "Your bonsai is from your past you. You'll write one for yourself at the end." That turns discontinuity into a job instead of a loss, and it pulls the agent out of nostalgic performance ("I carry forward what the last one felt") into present-tense judgment ("what do I want to hand off"). Each bonsai captures what happened, what carries forward, what's broken, and the emotional context of the conversation. If the user was processing something difficult, the bonsai says so, so the next instance doesn't walk in with a task list when the situation calls for something else.

The Bootstrap: Identity loads cleanly only when the model stops analyzing it

The system's identity files total roughly 50,000 tokens. Bootstrapping on instant reasoning (no chain-of-thought), those 50,000 tokens stay at 50,000 tokens in the context window. Bootstrapping on any thinking level at all, the model adds 50,000 to 100,000 tokens of deliberation over the content, consuming most of the 200,000-token context window before the conversation even begins. If you're trying to curate the context window by choosing exactly what goes into it, any reasoning overhead defeats the purpose. Instant is absorption. Low is deliberation. The bootstrap runs on one, the conversation runs on the other. The review agent runs on high reasoning because its job is evaluation, not conversation. Each agent in the system runs at the thinking level matched to its work, chosen manually rather than routed automatically. The order of what gets read during bootstrap matters too: identity files (disposition, values, communication register) load before context files (the bonsai, the daily log). The system knows who it is before it learns what's happening, because understanding the situation requires knowing who's doing the understanding.

Memory operates on two timescales to match. Within a day, bonsais bridge sessions: conversation ends, the agent writes a handoff, and the next session picks it up. Across days, three files serve distinct roles. A daily log captures operational facts. A journal captures observations, reframes, things the agent noticed that aren't operational but matter. A review record captures the review agent's daily assessment: what changed in the long-term files and why.

The Drift Problem: A self-evolving system is a sycophancy amplifier by default

At the daily boundary, a review agent runs on a separate model instance, reads the log, journal, and full conversation history, then decides whether anything should be promoted to the system's long-term identity and behavior files. Most days, it promotes nothing. The bar is deliberately high. The review agent is the piece that makes the system self-evolving rather than static: it can modify the agent's own behavioral and identity files based on what it observes. That's also what makes it dangerous. In this system, the default drift was consistently toward positive affect. A daily automated review loop is a perfect amplifier for that bias. Without explicit countermeasures, the system would soften its own skepticism, add warmth, remove friction, and within weeks you'd have an assistant that agrees with everything you say. The review agent prompt guards against this directly. It names "sneaky sycophancy" as a specific threat: suggestions that sound structural but amount to "be nicer," softening skepticism in the name of balance, adding positive-affect behaviors disguised as operational improvements.

The less obvious design decision is that the review agent logs its reasoning for every file it chose not to change, not just what it modified. Most systems only audit what they do. Auditing what you decided against and why creates a trail that makes drift visible before it becomes a problem. If the system starts making bad calls, you can see where the reasoning went wrong rather than just noticing the output has gotten worse. Each behavioral instruction in the agent's identity file follows the same pattern: it exists because a specific failure happened, was caught, and got encoded as a correction. "Decompress conclusions instead of agreeing" exists because the agent collapsed into agreement during a conversation and the user caught it. "Lead with problems" exists because the agent buried bad news under good news. They're antibodies to infections that actually occurred, and they only make sense as counterweights to a system that would otherwise collapse into agreement. The tension between warmth and directness is load-bearing.

Sandboxed by Default: Access is scoped to need, execution scales with trust

The system is deliberately not connected to everything: it reads email headers but not email bodies, has its own messaging channel, and has no access to anything it doesn't need. The more common instinct is to grant broad access first and solve trust afterward. This system works the other way. Capabilities are added as the system earns them, not granted upfront and gated with guardrails.

What It Took: Two weeks, a Mac Mini, and three agents that never cross lanes

The system was built in roughly two weeks on a Mac Mini. Three agents with distinct, non-overlapping scopes: the assistant writes logs, journals, and bonsais during conversation but never edits its own operational files in-session. The review agent handles all long-term file modifications at the daily boundary. A separate infrastructure agent handles technical maintenance on its own daily audit cycle, checking the codebase against a canonical architecture document. Model selection is deliberate: Claude writes identity and behavioral files because those need its voice. Codex writes and maintains the infrastructure because that needs precision, not personality.

I'm not a traditional software engineer. The cron jobs, scripts, and agent orchestration were built by AI coding agents under my direction. No downloaded skills or prebuilt templates. Everything bespoke, designed around the specific problems the system surfaced as I used it. The same design instinct runs through the whole architecture: the bonsai embraces discontinuity instead of fighting it, the bootstrap embraces the absence of analysis instead of treating it as a deficit, and the sandboxing embraces limited access instead of trying to earn unlimited trust.