Building useful apps and blueprints

Design apps and blueprints for an immediate first result, lasting value on return, visible agent work, trustworthy evidence, and useful collaboration.

Use these principles when asking your agent to build or review an app or blueprint. Agree on what makes it useful, then check the experience together. A blueprint should deliver a useful working setup for its next installer as well as for its creator.

Start with a job people care about

Name the person, the recurring problem, and the outcome that makes their day better. An impressive capability earns its place by helping that person make a decision or get work done. Explain the app's purpose in one sentence and make its main action obvious. Demonstrate a substantial workflow with real state, decisions and follow-through, while keeping the interface simple to understand.

Design the first visit, every return, and a colleague's arrival

Treat these as three separate experiences in the brief and the review:

Make the first useful result arrive as early as the work allows. Ask only for setup that unlocks it; let optional connections and refinements come later. State what that result will be before building, so the first-run test has a concrete outcome to look for.

On return, preserve corrections, decisions and unfinished work. Show freshness, last successful activity and meaningful changes. A quiet day can be valuable: say what was checked and that nothing needed action. Do not replay onboarding or manufacture novelty to give somebody a reason to return. History, outcomes and accumulated context should make the app more useful over time.

Make the first minute or two continuously useful

Open quickly, acknowledge input immediately and keep controls responsive while work runs. Avoid a blank screen or a spinner that leaves the person with nothing to do. As real work completes, reveal findings, source coverage, previews and decisions in a readable visual progression. Let the person inspect an early result, refine the scope or add useful input while later work continues.

Make each stage understandable: what is happening, what has finished, what is waiting on the person or a connection, and what comes next. Show partial results as partial. If blocked, explain the obstacle and offer the action that resolves it. Never invent findings, progress percentages or activity to fill the wait. Label sample data clearly and keep it separate from live results.

Use visual hierarchy and purposeful motion to make progress interesting and easy to follow. Respect reduced motion and avoid updates that steal focus or move controls while somebody is using them. Engagement comes from useful work and agency; once the work is done, let the person leave.

Make Bolter's app and agent connection tangible

An app should feel like a working part of Bolter: saved state, familiar access and sharing, responsive layouts, and agents that can act on what the person is looking at. Use the supported platform capabilities to serve the app's purpose.

Put specific actions beside the results that justify them, such as "Investigate this finding", "Draft a response" or "Check this again". Carry the selected item, evidence and relevant context into the agent's work so the person does not have to retype it in chat. Make clear which agent is responsible, show the request's progress and return its outcome to the relevant item in the app. An action is complete when the person can see what changed or why nothing did.

Invite meaningful input: correct a finding, rank priorities, approve a proposed action or ask the agent to develop the app further. Preserve that input and make its effect visible. Ask again when circumstances change enough to require a new decision, rather than repeatedly asking for the same preferences.

Put evidence beside the result

Show where important data came from, link to the underlying source where available, and state when it was retrieved or checked. Distinguish source facts, agent interpretation and user input. Make missing coverage, stale data, conflicting sources and uncertainty visible where they affect a decision.

Give completed work an inspectable receipt: what inputs and sources were used, what action ran, what output or change resulted, when it happened, and what was actually verified. Show failed checks and unverified claims honestly. A "verified" badge without a check the person can inspect is not evidence. Preserve enough context to understand a past decision after its source changes.

Use multiple agents when their roles improve the outcome

Consider two agents with complementary responsibilities, such as a researcher and a reviewer, or a planner and an executor. Make the division of work, handoff and contribution of each visible. This can demonstrate Bolter's support for agent teamwork through a result a single role would struggle to produce as well.

Give each step an accountable owner and a clear completion condition. A second agent should improve coverage, checking or execution enough to justify its time and cost. Two agents repeating a conclusion do not independently verify it; show the evidence and checks. Avoid agent chatter that leaves the person to coordinate the work themselves.

Make collaboration useful from the moment someone joins

Provide a clear way to share the work through Bolter's supported access controls and explain who can open it. Show what a colleague can contribute: review a finding, add context, take responsibility for an action or continue a task. Keep contributions attributable and decisions attached to the work, so joining does not require reading an entire chat history. Distinguish sharing the same working app from installing a separate copy of its blueprint.

Make it dependable enough to return to

Preserve work across closing, reopening and interrupted runs. Make retry, correction and cancellation understandable where supported, and prevent a repeated click or retry from accidentally repeating a consequential action. Explain the effect before that action and keep required approvals visible. Expose useful controls for recurring work, its cadence and its cost. Ask for access when it is needed and explain what it enables.

Make the core workflow usable on a phone, with a keyboard, and with assistive technology. Show useful empty, loading, partial and failure states. A blueprint must also work with another person's settings, sources and permissions; its creator's private data or connections must not be assumed to travel with it.

Review the experience with concrete evidence

Before calling an app or blueprint ready, walk through these scenarios and record what actually happened:

• A fresh installer supplies the minimum input, sees useful progress during the first minute or two, gets a first result and takes an action from it.
• A returning person finds saved state, understands what changed, and continues work without repeating setup. Also check the case where nothing changed.
• A colleague with the intended access understands the current work and makes a useful contribution. Someone without that access cannot see private data.
• A person traces an important result to its source and receipt, including what was and was not verified.
• An app action reaches the responsible agent and its outcome appears back in context. If two agents are involved, their handoff and distinct value are clear.
• Slow work, a missing connection, a failed check and reopening after an interruption each leave the person with an honest state and a way forward.

Measure time to the first useful result and completion of meaningful actions. Look for successful repeat use and colleague contributions. Time spent watching the app or the number of agent messages is not a substitute for value delivered.

See Apps and running code, Blueprints: sharing a setup someone else can run, Blueprints that carry an app, Processes an agent runs for you and Who can see what for the capabilities and access rules to build on.