Skip to main content

UI Structure

Brain’s UI has four surfaces. Each one has a clear job, and the boundary between them is intentional. The shape mirrors how operations work in practice: things arrive, things get asked, things get done, things get configured.

Inbox

Everything that needs attention lands here. Inbox is not only for human emails. It receives:
  • Client emails (RFQs, replies, follow-ups)
  • Agent messages (“I need your approval to create this style”)
  • Approval requests (every workflow’s draft preview)
  • Missing-field questions (“I couldn’t extract the currency — what should I use?”)
  • Duplicate detection warnings
  • “Needs review” notifications
  • Workflow exceptions (something failed mid-flow)
  • Risk alerts from the oversight agent
Example item:
The Inbox is where most of Mai’s daily approval work happens. It’s also where Zean sees risk alerts and ownership gaps.

Ask

Where users query and instruct the system in natural language. Ask is the chat entry point. Everything typed here goes through the aggregator agent, which classifies intent and routes to the right registered workflow. The aggregator enforces scope — anything that doesn’t map to a workflow gets the polite redirect. Two kinds of messages live here: Queries — read-only questions answered by Brain:
  • “What is the status of Jaspal style J26WGW153?”
  • “Show all RFQs waiting for quotation.”
  • “Which styles have true cost but no quotation?”
  • “Summarize latest client comments on this style.”
Instructions — natural-language workflow invocations:
  • “Draft a quote for Jaspal J26WGW153 at 18% markup”
  • “Create a new client from this sales contract” (with attachment)
  • “Generate a BOM from the tech pack I just uploaded”
  • “Send the quotation to Kaimook”
Both kinds land in the aggregator; the workflow that runs is whichever the aggregator routes to. Query answers are structured and source-linked per Manager Queries. Instructions invoke the corresponding workflow and surface its draft for approval.

Slash commands

For power-user invocation, every workflow is also exposed as a slash command (/create-style, /generate-bom, etc.). Slash commands bypass the aggregator — they invoke the named workflow directly with whatever parameters the user provides or attaches. Same workflow, faster path. Both paths are first-class. Mai might use chat for ambiguous requests and slash commands for things she does daily. The Inbox shows slash-command shortcuts on approval cards so she learns them naturally.

Task

Where work-in-flight lives. Two task types share this surface, clearly separated.

Human tasks

Operational work assigned to a person:
  • Create style
  • Review BOM
  • Assign material
  • Approve quotation
  • Follow up with a client

AI monitoring tasks

Background tasks Brain creates to track progress:
  • Watch this RFQ
  • Check for client reply
  • Alert if no quotation after 2 days
  • Track this negotiation thread

Task categories

The distinction matters because the right view for Mai is different from the right view for the oversight agent’s monitor list. Both live in Task, but filtered differently.

Engine

The technical / admin surface. Shows the system’s internals to people who need them:
  • Agents currently registered
  • Workflows defined
  • Tools available
  • Skills installed
  • Workflow runs (history)
  • Run status
  • Logs and traces
  • Connected systems (CutMake, email, Supabase)
Engine is the surface where engineers debug a misbehaving workflow, audit which tool produced which output, and configure system-level settings. Most merchandisers won’t open it.

Why these four

Each surface answers a different question:
  • Inbox: “What needs my attention right now?”
  • Ask: “What is happening with X?”
  • Task: “What’s in flight and who owns it?”
  • Engine: “How is the system itself configured and behaving?”
Collapsing them into one surface (a chat with a sidebar, say) makes everything worse: notifications get lost, queries get noisy, ownership gets unclear, and admin config drowns daily work.