Controlled Reasoning, Data Access, and Tool Use

Goal

The previous chapter explained how trusted data products are created from operational signals. AI and agentic architecture asks a higher-risk question: what happens when a system uses models, context, and tools to produce answers, recommendations, workflow steps, or business actions?

The durable idea is:

AI architecture controls what the system can see, say, and do.

The Short Version

A weak AI design starts with a model call:

Send the user question to a model and show the answer.

A stronger architecture starts with controlled capability:

User intent or business task
  -> Policy, identity, and context boundary
  -> Model reasoning and orchestration
  -> Retrieval and tool access
  -> Response, action, escalation, or refusal
  -> Evaluation, telemetry, cost, and change feedback

The model is important, but it is not the whole system. The architecture also includes prompts, policies, data access, retrieval, tool contracts, user identity, workload identity, safety controls, evaluation, telemetry, and owners for outcomes.

What Controlled Reasoning Means

Controlled reasoning does not mean the system is perfectly predictable. It means the system is designed with boundaries around the reasoning process and the actions that can follow from it.

Those boundaries include:

This is why AI architecture is not only prompt writing. Prompting matters, but prompts sit inside a larger system of data, permissions, tools, evaluation, and operations.

Seeing, Saying, and Doing

A practical way to design an AI workload is to separate three capabilities:

See  -> What context can the system access?
Say  -> What response can the system produce?
Do   -> What action can the system take?

Seeing includes retrieved documents, customer records, product data, order status, support history, telemetry, or internal knowledge. Saying includes generated answers, summaries, recommendations, classifications, drafts, and refusals. Doing includes tool calls, workflow requests, database updates, ticket creation, refunds, notifications, approvals, or escalations.

The risk increases as the system moves from saying to doing. A wrong answer can confuse a user. A wrong tool call can change business state.

Tool Use and Business Risk

Tool use turns model output into integration behavior. That connects this chapter back to the earlier chapters on APIs, events, workflows, data platforms, and ownership.

Not all tool calls have the same risk:

The tool contract should be narrow. An assistant that answers support questions should not inherit broad application credentials just because that is easier to wire up.

Human Escalation

Human escalation is not a failure of an AI system. It is a safety and operating pattern.

Escalation should appear when:

• The requested action is high impact, irreversible, regulated, or financially sensitive.

• The model lacks enough context to answer confidently.

• Retrieved information conflicts across sources.

• Policy requires review or approval.

• The user asks for something outside the system's allowed scope.

• The system detects safety, privacy, fraud, abuse, or compliance risk.

The design should define what gets escalated, what evidence is included, who reviews it, how the user is informed, and how the outcome improves future evaluation.

Example: Commerce Support Assistant

Consider a support assistant for a commerce platform.

It can:

• Answer return-policy questions from approved policy documents.

• Retrieve order status for the authenticated customer.

• Check shipment tracking and delivery promise information.

• Create a refund-review task for a human agent.

• Refuse or escalate requests involving suspected fraud, high-value refunds, or account changes.

It should not:

• Read unrelated customer orders.

• Invent policy details that were not retrieved.

• Issue refunds above approved thresholds.

• Call internal APIs with broad service credentials.

• Hide uncertainty when records conflict.

The architecture might look like:

Customer question
  -> identity and policy checks
  -> retrieve authorized order and policy context
  -> model response or plan
  -> read-only lookup, support task, refusal, or escalation
  -> audit, feedback, and evaluation record

The assistant feels conversational, but the architecture is a controlled workflow.

Common Mistakes

• Treating the model as the whole system.

• Letting tools inherit broad user or application permissions.

• Ignoring uncertainty and escalation paths.

• Assuming a fluent answer is a trustworthy answer.

• Designing the demo path but not the refusal, recovery, or audit path.

If Someone Asks You

What is the first design question in AI architecture?

A good answer is:

Start by asking what the system is allowed to see, say, and do. Then define identity, context boundaries, retrieval rules, tool permissions, output constraints, escalation paths, audit evidence, evaluation, and operating ownership. The model choice matters, but it should fit inside those controls.

What You Should Remember

AI systems need boundaries around context, output, action, and ownership.

Questions to Check Understanding

1. Why is tool use riskier than text generation alone?

2. What does the system need to control before calling a model?

3. When should human escalation be designed explicitly?