Build intelligence
people can work with.
We want useful AI to be connected, inspectable, and bounded. These are design commitments, not claims that software can replace judgment or that every deployment already gets the details right.
01what we choose to optimize for
Six principles. Each changes the work.
Start with the job, not the catalog.
The first question is not how many models a workflow can reach. It is what a person needs to accomplish, which inputs are legitimate, and what a useful result would allow them to do.
Practical implicationChoose one task and an output boundary. A draft, an explanation, and a decision are different jobs. Give the workflow only the capabilities that job needs.
Context should answer for itself.
A remembered fact or retrieved paragraph is not automatically current, relevant, or authorized. A confident response without a readable source trail can make a weak assumption harder to notice.
Practical implicationBuilt-in MCIR memory should carry relevant history, not freeze old assumptions. Preserve source identity and freshness, leave gaps visible, and give people a way to correct the context.
Permission belongs outside the prose.
A prompt can describe how a system should behave. It cannot stand in for authenticating a person, authorizing a resource, binding a policy, or constraining an external action.
Practical implicationKeep secrets and execution checks in the application. Verify actual scopes and bindings. A generated claim of approval must never grant approval.
A visible stop is better than an invisible detour.
Not every request has a valid path. A missing source, disconnected model, or ineligible tool is important information, not an inconvenience to hide behind another plausible response.
Practical implicationExpose the failure and give it a recovery path. Do not silently bypass a configured boundary to make the interface appear successful.
Review belongs where consequences begin.
Drafting a note is not releasing it. Preparing a task is not executing it. People affected by a result deserve an owner who can explain, correct, or reject what happened.
Practical implicationPut meaningful review into the application before consequential actions. Decide who has authority, what evidence they see, and how errors are corrected.
Let the evidence set the size of the claim.
An architecture, a synthetic demo, an offline verification run, and a live evaluation tell different stories. Treating them as interchangeable makes a product easier to market and harder to trust.
Practical implicationState the tested build, configuration, mode, and limitations. Do not report a deterministic fixture as model quality or a scoped control as universal protection.
02what this looks like on the page
Replace “take care of it” with a reviewable instruction.
A narrower brief
Instead of: “Handle this equipment return.”
Write: “Use the approved return-policy excerpt to draft an explanation. Include its source label. If the destination is missing, say so. Prepare no shipping label and make no change to an asset record.”
Then implement: read-only source access, a bounded response, and process-owner review before any external action.
The instruction and the enforcement need each other.
The narrower brief makes the intended behavior reviewable. The application controls make the boundary real. Neither a neat diagram nor a good prompt excuses us from checking the actual execution path.
When a source is unavailable, the honest output can be a question. When a tool is denied, the useful next step can be a review. An interface should make those outcomes understandable instead of rewarding only uninterrupted generation.
follow the complete operations example03hold the product to the principles
A principle is useful only when you can question it.
Read the implementation contract before relying on a control. Gateway Guardrails are opt-in and bound to API keys; a policy that exists but is not bound does not enforce itself. Read the research limitations before borrowing a claim from a protected path.
Use the public workbench to ask what changes when the inputs or configuration change. Use documentation and deployment-specific verification to establish what the real system does. Keep the distinction visible.
Put the principles under a little pressure.
Change a source, route, or mock permission in the workbench. A useful explanation should survive a stopped path.