The hard part of prompt-to-app is knowing what changed

The user writes one paragraph, waits, and sees a different application. Then the practical questions arrive: is this still working, what did it touch, and am I looking at a saved result or a temporary one?

Those questions describe three different kinds of state:

• operation state: what the agent is doing now;
• product state: what changed in the application;
• decision state: whether the system needs an answer from the user.

The interface has to distinguish those states without exposing a stream of internal tool calls. A useful builder translates agent activity into a small, stable contract the person can learn.

During a Mythos build, the chat shows the latest file action. After delivery, the completed turn keeps the full changed-file trail under Details. That provides useful evidence without dumping the model's hidden reasoning or a full terminal transcript into the conversation. The workspace switches between preview and code instead of cramming both into one narrow panel.

The distinction between working state and saved state matters. File activity can stream while the agent works in an isolated stage. The project is not presented as delivered until the completion checks pass and the result is committed. If the run fails, an unfinished stage should not quietly become the new source of truth.

This gives each surface one job:

Preview state should expose its Git revision and synchronization status when available. Even then, a working preview is evidence for the flows you exercised, not proof that the application is correct. More detail should be available when it helps investigation; it should not be the price of basic orientation.

Status also has to work when the user is not watching the exact pixel that changed. The W3C guidance for accessible status messages covers progress, success, and errors that assistive technology can announce without moving focus. The Mythos progress card uses a polite live region for stable in-progress status; individual file events remain visible without each one joining the announcement queue.

Asking for approval before every file change sounds safe and quickly becomes unusable. The better boundary is the point where an implementation choice becomes a product choice: visual direction, scope, data ownership, or a promise made to the user's customers.

Mythos exposes two paths. Build mode starts one bounded autonomous implementation slice. Plan is a separate, durable, read-only conversation: each accepted AI turn costs one credit, while Save, Approve, and Cancel do not add another Plan charge. Plan changes no project files. Approval freezes the exact saved plan and hands only its opaque identity to a normal Build, which carries the ordinary create or edit price. There is no hidden Continue workflow.

That design follows a broader pattern. Google PAIR's guidance on feedback and control argues for balancing automation with the ability to edit and regain control. OpenAI's practical guide to building agents recommends human intervention when failure thresholds are exceeded or actions are high risk. Approval belongs where a wrong assumption would change the product, not before routine implementation steps.

An agent interface should describe its control contract exactly. Plan can return questions, messages, and a draft without mutating project files. Each accepted AI turn costs one credit; saving the current draft is free. Approval preserves the exact plan version, but implementation still starts through a deliberate, normally priced Build. Build has an explicit Stop control in the same place as Send. A Build that cannot safely finish terminates once with a clear outcome instead of creating a hidden checkpoint workflow.

Control also does not mean exposing chain-of-thought. The user needs observable state, the proposed plan when Plan mode is used, changed files, and the resulting application—not private model reasoning presented as if it were an audit log. Those product contracts can be tested without publishing private model reasoning.

A clean model stop is not enough to mark a build complete. Mythos requires an explicit builder_done result and then runs host-owned policy, structure, type, production-build, and browser-render checks. A response that never reaches an accepted completion result fails and cannot deliver partial staged files.

The user-facing contract has two terminal outcomes: a committed result, or one clean failure message with the authoritative billing outcome. A reservation is returned when model work never started; once model work starts, the database-owned billing policy decides the final state. The UI reports that state and never guesses from an HTTP error. Technical provider details belong in operator telemetry and the generation-run record, not in the chat. The terminal message has to answer two questions directly: did the project change, and was I charged for a result I did not receive?

Failure should return control. It should not leave a permanent spinner, an ambiguous half-save, or a raw SDK error that asks the user to diagnose the platform.

You can begin a user-facing audit without seeing the system prompt. Start a build and ask:

1. What is the system doing now?
2. What has changed so far, and what is only temporary?
3. Which version is the current saved source of truth?
4. Does the system need an answer from me?
5. What happens to the project and the charge if this operation never finishes?

The happy path can answer the first four questions. The fifth needs a controlled timeout or failure test plus evidence from the Git revision, generation run, and credit ledger. When those surfaces disagree, the user cannot tell whether to wait, retry, or contact support. The fix is to define the states, enforce the transitions, and use language that remains true when something goes wrong.