Make important claims checkable
A useful claim has a source and a clear scope. Our approach is to distinguish what a source establishes from what an agent infers, and to pause unsupported claims before they become client-facing commitments.
The same discipline applies to our own case records: a historical benchmark is not measured savings, and delivery is not proof of continuing operation.
Source checking needs to happen close enough to delivery to catch a claim that changed during drafting. If the available evidence does not support a statement, the statement needs to be narrowed or held for clarification. This is a review principle: the output should say what the evidence establishes, and the reviewer should be able to tell the difference between that and an inference.
Give access a defined purpose
Permissions should match the task. Client information needs deliberate boundaries, and credentials should be handled through the systems intended to hold them.
These are design and operating principles. This page does not assert that a single configuration or control has been verified across every client environment.
A useful role definition says what information the agent needs and which actions it may take. Different client contexts need deliberate separation. Credentials and access are part of that design, with the implementation checked in the environment where it will operate rather than assumed from a general description of the approach.
Separate preparation, approval and verification
We distinguish drafting work from sending or publishing it. Actions with meaningful consequences need an identified person responsible for approval. Review should be sufficiently independent to find errors rather than simply repeat the first result.
A runbook should explain what happens when the system cannot proceed and how a person takes over. A failure that nobody notices is an operating problem even when the underlying model performed well.
Reversibility also matters. Preparing a draft is easier to undo than sending it to a customer or changing an external system. Making that distinction explicit helps identify where approval belongs. Verification then asks whether the intended result actually happened, rather than treating an attempted action as proof of success.
Describe controls with their evidence
Our published operating notes discuss narrower roles, explicit handoffs and ongoing attention to agent systems. These are lessons from practice, not a certification. [1]
Questions & answers
A few useful distinctions
Why separate preparation from action?
Drafting a recommendation and sending or publishing it have different consequences. The workflow needs to identify who may approve the action.
What makes a claim checkable?
A source, a clear scope and wording that matches what the source establishes. Inferences need to remain distinguishable from verified facts.
Why should review be independent?
A reviewer needs to find errors rather than repeat the reasoning that produced the first result. Independence helps keep review from becoming a rubber stamp.
What should a support runbook explain?
What to do when the system cannot proceed, who should know, how a person takes over and how to check that work resumed correctly.
Is this a security certification?
No. It describes an operating approach. Controls and assurances for a particular client environment require evidence from that implementation.
How does reversibility affect approval?
An easily revised draft and an external action carry different risks. The harder an action is to undo, the more important a clear approval boundary becomes.
Public sources
These links provide the public material and background identified below. Client engagements are described by type.
- Start with the org chart, not the model
Published operating perspective on roles and agent organization.
- Six months inside an AI agent organization
Published lessons from operating agent workflows; not a client security attestation.