I'm a conversational AI experience designer and former Head of Applied AI at Huzi, an AI-first real estate startup.

AI systems are only as useful 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.

I came to this work through the problems directly in front of me. As a real estate agent, I built research tools, objection-handling systems, and neighborhood analysis prompts. 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, evolving behavior, and autonomous daily operations.

Ultimately, every system meets its users in a conversation. If that conversation engages them, it unlocks the system's value.

AI System Design for an Enterprise Real Estate Client

The ask: eight professional domains, end to end

At Huzi, a national title insurance company asked us for AI tools covering eight professional domains across three user groups: real estate agents, title and escrow sales reps, and internal marketing technology directors. Transaction coordination, sales, marketing, lead generation, social media in two variants, B2B conversion, SEO and 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, and track compliance deadlines. The sales coach request listed roughly twenty use cases of startling specificity: a "12-week multi-channel cadence," an "automated scorecard capturing talk/listen ratio." It also contradicted itself. One requirement said to ask at most one or two clarifying questions and otherwise proceed with defaults; another said never make assumptions, always ask the requester to clarify. One section specified a 6th-to-8th grade reading level; another said 12-year-old. These requirements hadn’t been reconciled.

This is the modern requirements problem: an exhaustive, specific, unbuildable document, generated faster than anyone can sanity-check it. The job was to read through the document to the work underneath it.

The translation

End-to-end autonomy was the wrong target for a second reason beyond feasibility. Chaining autonomous steps through high-liability professional work compounds the failure rate at every link: wrong data in an MLS field, a missed compliance deadline, a communication sent to the wrong party. The responsible version of what the specs described would have required integration depth and validation layers far beyond the engagement.

So each domain got reframed around the distinct, repeatable tasks that sit underneath the high-stakes work. The twenty-odd sales coach asks became five focused plays: a lead management planner, a time management assistant, a script writer, a conversation analyzer, and a negotiation preparer. That reframing happened eight times, once per domain, and each deliverable included what not to build and why.

Sometimes the deliverable was the no itself. When the client later asked for a social media coach serving all three user groups, I sent a scoping memo instead of starting the build: caption writing for an agent targeting consumers is a different job from caption writing for a sales rep targeting other agents, so "building for three audiences with separate frameworks and compliance considerations is functionally building three separate coaches. That's 9-15x the architectural complexity of anything we've delivered so far." The multiplier was napkin math and I knew it, but the shape of it was the argument. I recommended building it purpose-built for agents on the current timeline, scoping the other two audiences as separate builds with their own requirements, and then proceeded on that recommendation rather than waiting for sign-off, because the deadline didn't wait either.

The system

Each coach is built on a single master prompt: a frameworks knowledge base synthesized from the books, methodologies, and industry experts the client specified, plus 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 a specialized play. Each play is the same master prompt with a task module appended, so the coach's identity and rules stay identical across every entry point.

The two social media coaches show why the architecture had to work this way. They share five play names (caption writing, video scripts, bio optimization, engagement strategy, response library) and serve completely different users: one is built for agents doing client acquisition, the other for title reps developing B2B partnerships. Same structure, different frameworks and strategic intent underneath. Knowing when two things that look identical need to be built separately was a recurring part of the work.

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

The testing

An architecture diagram is not evidence that any of it works, so the plays went through adversarial roleplay before delivery. Roleplay isn't an eval suite; it was the fastest way to find the failures worth fixing before real users hit them. I had a second AI play the least AI-savvy agent it could honestly simulate, with instructions to "use sample information and don't make it too easy for the AI," and ran the same test in separate conversations so one lucky run couldn't fool me. My brief for the simulated user, from a later session: real users "don't know how to give necessarily enough context... We want to make the agent, the AI, get us 51% of the way there. And this is a professional, right? This isn't a therapy thing."

Both brand-building runs found the same failure. The play opened by asking for five things at once: production level, target market, existing brand elements, twelve-month goals, differentiators. One simulated agent gave rambling half-answers ("I closed maybe like 15 deals last year? Some were pretty good ones") and finally asked, "Is this enough information or do you need more? I'm not really sure what you're looking for here." The other ("For branding I literally have nothing lol") ended with "Can you just tell me what I should be doing?" A user who can't answer your intake question doesn't need a better-worded question; they need the assistant to start from almost nothing. The same month I rewrote the prompts' follow-up rules around a related failure, stacked asks after a draft, landing on: choose one type of follow-up, a request for information or a strategic question, and "never combine both in the same message."

The maintenance question got its own answer later, when the whole system migrated to a new platform version: roughly 600,000 tokens of prompt content moved with byte-level verification against the originals rather than spot checks, on the argument that a deployed prompt system is like a space telescope, you can't fix the errors you discover after launch. The verification caught an AI-assisted refactor that had quietly rewritten content instead of copying it, which is exactly the class of error spot-checking misses.

The deeper fix came from watching the coach's conversational habits across a whole session. An early version carried the rule "Always conclude with 1-2 thoughtful follow up question." It produced exactly what it asked for: a question at the end of every message, forever, which reads as robotic by the third exchange. The final version deletes that rule and replaces it with a framework for question quality: at most one question, a taxonomy of the question types worth asking, and named anti-patterns written directly into the prompt. The Obvious Echo ("so it sounds like follow-up is challenging for you?"). The Therapy Prompt ("how does that make you feel?"). The Motivational Poster ("are you ready to take your business to the next level?"). The Repeat Offender, ending every single response with a question. The decision logic ends with a test: "Could I coach them forward without asking this?" If yes, don't ask.

The takeaway

The prompts are the artifact. The decisions about what to build are the work. Every domain started with a specification describing the most technically demanding version of the job, and the recurring move was finding the high-leverage, low-fragility tasks inside it, building coaching tools around those, and then testing the result against the least prepared user I could imagine instead of the most impressive demo I could give.

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" - A Personal AI Assistant With Transparent Context Curation

The Problem: Default compaction hides what the model has lost

Aloha is a custom version of OpenClaw running on a Mac mini, and I interact with it through iMessage. OpenClaw compacts by default: when a session nears the model's context limit, a separate model request summarizes the older turns into a compact entry and the recent turns are kept. The full history stays on disk, but the model works from the summary.

That's a reasonable default for code, where the deliverable is the file on disk. For a personal assistant, the conversation is most of what the system has to work with, and a summary drops what's hard to summarize: what was actually said, and details that only matter later. In my use, the assistant started losing things that had already been discussed, and because compaction runs silently, I had to guess what it still had and never knew when the summary had happened. The model didn't know what it was missing either. When a fact dropped out, the gap got filled with a confident guess, and the guess became part of the record later turns built on.

The goal was transparency for both me and the model: a system that works like one long, unbroken interaction and is honest about its limits, instead of one that performs well at first and degrades quietly over time. Most of the system follows from that.

The Bonsai: The main session decides what carries forward

I disabled default compaction. When the context window starts filling, the assistant flags it and offers to bonsai and reset. It's always a judgment call, and I usually take it at a natural break: a project wrapping up, or a switch to a different task. The main session then writes a handoff note I call a bonsai, because the point is pruning: deciding what to keep and cutting the rest on purpose. That judgment is made by the session that has the full conversation in context, rather than by a separate request whose only job is to compress older turns.

The next instance starts from an accurate account of where things stand and how they got there, so it continues instead of guessing. The note is a file I can read, so what carried forward is visible to both of us.

The Nightly Review: The assistant's instructions are rewritten every day

The bonsai is a smaller version of what happens overnight. The bonsai decides what carries into the next conversation; the nightly review decides what carries into the next day, and it's the part of the system that changes how the assistant behaves. Each night, a separate review agent reads the day's journals and bonsai files, rewrites the assistant's own instructions, updates its profile of me, and flags what's still unresolved. The next morning the assistant starts from those updated instructions, and its first message raises the unresolved items, so I don't have to re-explain where things stand.

The design decision I'd point to first is that the review records what it leaves out, not just what it adds. Every change is logged with what it changed, what it considered changing and rejected, and why, so the omissions sit on the record next to the changes. That log is where I check when curation goes wrong.

The Drift Problem: Recency bias in a loop that edits its own instructions

The review agent is what lets the system change over time, and it's also the main risk. The problem I actually hit was recency bias: whatever came up last carried more weight than it should, and it shows up in omissions, as the latest thing crowds out what mattered more. That's why the omissions log exists. Early on, an offhand remark could travel from the daily log into a handoff note, get promoted by the review, and show up the next morning as an established fact about me. The fix was a rule that log entries are context, not policy: only explicit requests become standing behavior, and when the assistant summarizes what I want, it quotes me and labels its own inferences.

Sycophancy is the other thing the review guards against. Every LLM leans toward agreement, and in a long-running system the review is where changes to behavior get made, so I put anti-sycophancy instructions in the review prompt as well as the chat persona. The review prompt names "sneaky sycophancy" as a specific threat: suggestions that sound structural but amount to "be nicer." Logging what it decided not to change makes drift visible in the review record before it shows up in conversation. The behavioral rules follow the same logic. "Lead with problems" exists because the assistant once put bad news underneath good news. Each rule traces back to a specific failure I observed.

How It's Built: Daily use since February, built by AI coding agents under my direction

The first version took about two weeks. It has been revised continuously since, through several model migrations. The conversational assistant writes its log, a journal, and handoff notes, and the review agent edits the long-term files.

I'm not a traditional software engineer. The scripts, scheduled jobs, and orchestration were built by AI coding agents under my direction, and most of the design came from problems that surfaced in daily use rather than from a plan at the start.