Designing evidence-grounded AI preparation for commercial decisions

01The reality · current state

What happens today—or in the pilot.

Commercial decisions start with context assembly. Before a visit, a salesperson needs the account, its contacts, recent activity, open opportunities, orders and invoices, performance and what was promised last time. Before the monthly performance review, a manager needs the published numbers, what changed since the previous review, the recovery plan and which actions are overdue. The information exists—in several systems, at different freshness. People open several screens, build an export or a presentation, reconstruct what changed by hand, work from memory—or go in unprepared. A generative summary is attractive and risky: it reads well even when a source is missing, stale or wrong.

• Preparation depends on each person’s habits and the time they have
• A pilot visit summary mentioned an order that had been cancelled
• A pilot review page recommended a price reduction nobody could support
• Numbers in the summary did not match the published dashboard
• Conflicts between CRM and ERP were silently averaged
• Nobody could tell which statements were facts and which were guesses
• Summaries pasted into notes became “facts” later

02Work decomposition

Reasoning, rules and authority—kept apart.

Before any model reads anything, the work is split by what it needs: reasoning a model can do, rules a system enforces, and authority that stays with the person who decides.

Reasoning does not imply authority: the model reasons over context the rules assembled, and its output is a brief, not a record.

03Context contract

Every source has standing; every line has a type.

Context is architecture. Every source must be relevant, trusted, timely, permitted, identified and structured before it reaches the model—more tokens do not replace governed context. The contract is written per source before any prompt: what it is, what standing it has, how fresh it must be, which entity it refers to, which version counts, what AI may use it for and how the reader traces a statement back to it. Context is never flattened into “what the model received”: a governed analytical fact, an operational fact, a person’s account of a meeting, an external item and the model’s own inference have different standing—and the brief shows which is which. No real field or object names.

04Agent workflow

Each step with its actor, its tool and its authority.

Systems and partiesCRMERPData platformCalendar

1. 01
   Trigger

   A visit on the calendar or an account on the review list—never a free-form request to “look into” a customer.

   SystemRead
2. 02
   Resolve identity

   One governed account key, within the requester’s visibility; no briefing until it is unambiguous.

   SystemReadRead account context
3. 03
   Assemble context

   Each source read through its contract: standing, freshness and version attached to every value.

   SystemReadRead recent transactions
4. 04
   Published signals & open actions

   Only published signal versions; open actions with owners and due dates.

   SystemReadRead published signals
5. 05
   AI preparation

   Summarizes, compares, flags anomalies and writes questions; every statement typed and cited.

   AgentRecommend
6. 06
   Human decision

   The salesperson or manager reads, challenges and decides; records are written by people.

   HumanHuman approval

05Key dimension · Context contract, typed evidence, read-only authority

Governed context in, a typed and cited brief out

Context is assembled by rules before the model reasons. The model’s output is a brief whose every line has a type and a trail back to its evidence. The decision sits outside the architecture’s reach.

A model’s confidence is not evidence. A statement is trusted because it traces to a source, a version and a record—and a cause the evidence does not support becomes a question.

06Tool & authority boundary

Bounded read tools—never raw system access.

The agent does not call platform interfaces. It calls four read capabilities whose contracts fix purpose, inputs, identity and permission scope, output, freshness and failure behaviour. None of them has a side effect—and that is visible in the contract, not promised in a prompt. Tool names are descriptive, not implementation names.

Authority by action

07Ambiguity policy

When the agent is unsure.

• Stale dataStop

  Marked stale or left out—never presented as current

• Conflicting dataContinue

  Both values shown as a conflict, never averaged; if the published numbers themselves conflict, the brief is not produced

• Missing contextContinue

  The brief states what is missing instead of filling the gap

• Unknown causeAsk

  Phrased as a question for the conversation or the account owner

• Identity uncertaintyStop

  No brief until one account is confirmed—context from two possible customers is never mixed

• No evidenceStop

  The claim is not made

08Human review

Review where ambiguity becomes consequential.

Human review is not “a person checks the AI”. The person receives a brief built for judgement—and keeps everything that is judgement.

09Evaluation

Scored per dimension—never one accuracy number.

10The trade-offs

Credible options, judged against these premises.

11Audit, governance & learning

Consequential activity can be reconstructed afterwards.

A brief that shaped a decision can be reconstructed afterwards—without a logging interface anyone has to read every day.

12The second layer

Questions that change the design.

13Decisions & outputs

What the work produces.

• CaseDesigning the operating cycle behind field commercial execution
• CaseDesigning account management as a performance, development and recovery system
• CaseDesigning a governed commercial performance data model
• CaseDesigning embedded commercial analytics around management decisions
• CaseRunning commercial management cadence from the CRM