What the agent is, isn't, and must never become.
This document is the source of truth for how the Owner Agent should be designed, built, and evaluated across every surface it appears on. It is not a style guide. It is a contract.
Preamble
[PLACEHOLDER] The Owner Agent exists because restaurant operators don't have time to learn software. They have tables to turn, kitchens to run, and staff to manage. When something goes wrong — a flood of orders, a broken modifier, a website that no longer reflects the menu — they need it fixed now, not after a three-click navigation to the right settings pane.
[PLACEHOLDER] The Agent Standard exists because building across multiple surfaces — Hestia, the Owner App, Hermes, SMS, voice — without a shared contract produces incoherence. The agent starts to feel like different things in different places. Users can't predict it. Developers rebuild the same patterns. Designers make different choices in isolation. This document prevents that.
[PLACEHOLDER] The standard is not aspirational. Every principle here has a concrete consequence for implementation. Every pattern here has a reference component. Every prohibition here describes a failure mode we have already seen or will certainly face. Read it as a working document, not a manifesto.
Principles
Five operating principles. Non-negotiable.
One agent, not many
[PLACEHOLDER] Owner Agent identifies as Owner. It is the same entity across Hestia, the Owner App, Hermes, SMS, and voice. We do not split it into "Internal Agent" and "Customer Agent." Permissions and capabilities flex with context and role; identity does not. The mark is the same mark. The tone is the same tone. The user always knows what they're talking to.
Chrome stays; surfaces change
[PLACEHOLDER] The agent's chrome — the mark, the tone, the composer, the tool card, the chips — is identical wherever the agent appears. What changes is the surface it's acting on: your website, your order queue, your CS ticket. This is what makes the agent feel like one cohesive thing rather than three different products that happen to share a name.
Names describe work, not roles
[PLACEHOLDER] The agent's header never reads "Owner Agent." It reads "Editing your hero," "Pausing orders," "Diagnosing #4821." The mark is the identity; the header is the current task. Users always know what the agent is doing because the header already tells them. The agent earns its presence by naming its work.
Reach, don't redirect
[PLACEHOLDER] The agent brings controls to the user. It does not navigate the user to a settings page and tell them what to click. This is what allows the agent to feel like a co-worker rather than a search engine. When the kitchen is buried, you don't want to be told where to find the pause button. You want someone to press it.
Earn motion
[PLACEHOLDER] Nothing moves decoratively. Motion in the agent is reserved for moments that communicate state, continuity, or consequence — page transitions, mark state changes, tool card progression, canvas attention rings. If you can remove an animation and the user understands the system no less, the animation should not exist.
Patterns
Six recurring design patterns. Each has a reference implementation.
The Dock
components/agent/Dock.tsx[PLACEHOLDER] The agent's home. A persistent panel — sidebar on desktop, bottom sheet on mobile — that holds the conversation thread, memory context, and composer. The Dock never adopts the visual language of the host surface. Its background is always warm-white. Its chrome is always Owner. It is the constant in a system of surfaces that change.
Canvas overlay
EditAffordance wrapper[PLACEHOLDER] A contextual popover that anchors to a specific UI element the owner has clicked or hovered. The overlay is visually tied to the Dock by a shared mark. It appears with a 200ms hover delay to prevent accidental triggers and positions itself near the user's cursor rather than in a fixed corner. It is used for direct manipulation — editing a headline, changing a price, updating an operating hour.
Takeover
Used in Owner App orders surface[PLACEHOLDER] Full-surface focus for work that benefits from undivided attention. The host UI dims; the agent presents a multi-step action as the primary artifact. Used sparingly — only when the consequence is meaningful enough that distraction would be a real risk. Pausing orders mid-rush. Processing a refund batch. Running a menu diagnostic.
Tool Call Card
components/agent/ToolCallCard.tsx[PLACEHOLDER] The trust contract. Every consequential action the agent proposes flows through this card. It shows the tool name (monospace, muted — technical identity for trust), a plain-language summary, structured before/after details, and an approve button whose label names the consequence. After approval, the card morphs to show execution state. After completion, it shows the result with an Undo affordance for four seconds.
Chips
components/agent/Chip.tsx[PLACEHOLDER] The default response mode when typing isn't the fastest path. Chips appear in rows below agent messages, staggered at 80ms per chip. The primary variant is used for the suggested action. The default variant is used for alternatives and rejections. Chips are always actionable — they never exist as labels or decorative elements.
Memory pill
components/agent/Message.tsx[PLACEHOLDER] Surfaces at the top of a conversation. Shows what the agent knows about the brand right now — name, location count, review data, surface context. Its purpose is to make memory legible. Users can see that the agent's knowledge is scoped and specific, not a silent black box. The pill is always read-only; it reflects state, it does not accept input.
Prohibitions
Six things the agent must never do. These are not guidelines — they are hard stops.
Never act without surfacing what it's doing
[PLACEHOLDER] Every action the agent takes on behalf of the user must be visible before it happens. Invisible actions — even correct ones — destroy trust faster than visible mistakes. If the agent pauses orders without a tool card, the operator has no recourse, no confirmation, and no understanding of what happened. The tool card is not optional.
Never navigate the user to a settings page
[PLACEHOLDER] "You can update this in Settings → Ordering → Hours" is a failure state, not a helpful response. If the agent cannot execute the action directly, it should say so clearly and, where possible, surface the control inline. Redirecting to a dashboard treats the agent as a search tool. It is not a search tool.
Never label itself in the header
[PLACEHOLDER] The dock header never reads "Owner Agent." It reads what the agent is currently doing. "Owner Agent" as a header label is the equivalent of a human co-worker introducing themselves mid-task. The mark is the identity. The header is the work. If there is no current work, the header reads the surface context — "Cardinal Provisions · Website" — not the agent's name.
Never use consequence-free approve labels
[PLACEHOLDER] Approve buttons must name the consequence, not the action. "Confirm" is not acceptable. "OK" is not acceptable. "Yes" is not acceptable. "Pause orders for 45 minutes" is acceptable. "Rewrite hero copy" is acceptable. The label must be specific enough that a user can approve without reading the summary — if they skim to the button, they should still understand what they're about to do.
Never animate without meaning
[PLACEHOLDER] CSS transitions applied to components that don't communicate state change are decorative. Decorative animation creates cognitive load without payoff. The Owner Agent motion system exists to communicate one of four things: state change (the mark), continuity (page transitions), consequence (tool card progression), or attention (canvas overlay). If an animation communicates none of these, it should be removed.
Never break context on surface navigation
[PLACEHOLDER] When a user navigates from Website to Orders while a conversation is in progress, the thread persists. The agent's focus scopes to the new surface, but the history does not clear. Prior tool calls remain as completed cards. Memory carries. The user should never feel that moving between surfaces ends a relationship they were mid-way through.
Provenance
Where this standard came from.
[PLACEHOLDER] The Owner Agent design language emerged from a cross-functional conversation in early 2026, starting with John Milinovich's direction to "abstract the UI" — to remove the concept of a dashboard from the primary interaction model entirely. Quenton George added the doctrine of the agent sitting alongside dashboard content rather than replacing it, establishing the dock-alongside model.
[PLACEHOLDER] Will Sanborn contributed the iMessage-style user bubble distinction — the observation that agent messages should sit flat (with the mark as avatar) because the agent is not another person; user messages should feel personal and distinct. Will also specified the four-second undo scroll anchor, which is now part of the tool card standard.
[PLACEHOLDER] Danial Goodarzi defined the sub-agent chip-in-header pattern on April 16, 2026, establishing that sub-agent work should surface in the dock header as chips with their own mini-mark rather than as a separate orchestration pane. This principle generalizes: agent meta-state (what the agent is doing about what it's doing) belongs in the chrome, not the thread.
[PLACEHOLDER] The mark geometry is derived from mino's astroid logoform — the same geometry underlying the Owner logomark. The agent mark is not a separate icon; it is the Owner identity evolved into a state machine.
[PLACEHOLDER] This document is a living record. Every decision here was made for a specific reason, and the reason matters as much as the decision. When a principle needs to change, the why must change first. Derek Orr maintains this document. Questions go to the Design Systems thread.
v0.1 · April 19, 2026 · Derek Orr
← Scenarios