Key takeaways
- Authority is designed, not discovered. List what the agent may read, write, and trigger before you ship the chat box.
- Tools are permissions. Every connector is a capability grant — scope it like an API key, not a party trick.
- An action without a log is a defect. If support cannot reconstruct the thread, rollback is guesswork.
The agent refunded the wrong invoice. Support could see the customer's anger. Nobody could see which tool call fired, with which account ID, under which policy.
Adding an AI agent to a product is not a chat widget decision. It is an authority decision: what the system may read, what it may write, what it costs per action, and who catches the exceptions. How AI changes creative production covered the studio edge. This page is product architecture — permissions, ledger, escalation — before the demo ships.
Run the authority inventory first
Before you wire tools, list capabilities as if you were onboarding a junior employee with root access.
| Layer | Document |
|---|---|
| Read | Which records, fields, and documents may enter context? PII boundaries? |
| Write | Which systems may the agent create or update rows in? |
| Trigger | Which external actions — email, refund, deploy, ad spend — are allowed? |
| Deny | What is never automated — legal holds, pricing overrides, bulk delete? |
| Escalate | Which confidence or risk scores hand off to a human with full context? |
The NIST AI Risk Management Framework treats measurement, governance, and human oversight as core functions — not post-launch paperwork. OWASP's Top 10 for LLM Applications names excessive agency and insecure output handling as recurring failure modes. Your inventory is how you answer both frameworks in one sprint.
If you cannot fill the deny row, you are not ready to ship.
Surface the boundary in the product, not only in internal docs. Users should see when the agent acts on their behalf versus when it suggests. Google's People + AI Guidebook recommends setting expectations about system capabilities and failure modes — the same discipline applies to B2B tools with write access.
Disclose automated actions in the thread: "I updated ticket #4821" beats silent writes. Offer undo or human review when the action is irreversible. A chat box without boundaries trains users to treat the model like omniscience — then blame you when it is not.
Tool permissions are the product surface
"Tool use" sounds technical. In practice it is scoped API access with natural language on top. Anthropic's tool use documentation describes structured calls the model may invoke — each one needs explicit schema, validation, and server-side enforcement. The model proposes; your backend disposes.
Rules that survive contact with users:
- Validate on the server. Never trust the model's JSON as authorization.
- One action per intent. Compound tool chains hide which step failed.
- Idempotency keys on money and inventory writes.
- Read-only tools for exploration; write tools behind confirmation or role checks.
- Rate and cost limits per user and per tenant — agents spend tokens and API calls like features.
Custom software vs no-code named durable state and audit as the line between glue and product. An agent that writes to CRM without a log is no-code chaos with a friendly avatar.
Cost ledger and human escalation
Agents have a unit economics problem. A support bot that loops on tool calls can burn more than the ticket was worth. Track:
| Metric | Why it matters |
|---|---|
| Tokens in/out per resolved thread | Margin on automated support |
| Tool calls per session | Loop detection |
| Escalation rate | Whether humans are the real product |
| Time to human pickup | SLA when authority ends |
| Rollback count | Whether write tools are over-scoped |
Escalation is not failure. It is design. Pass structured context — user ID, attempted tools, redacted transcripts, proposed action — so the human does not replay the thread from scratch.
Audit: reconstruct any action in support
Test before launch:
1. Pick one completed agent session that included a write tool. 2. Without re-running the model, list every tool name, input hash, output status, and timestamp from your log store. 3. Replay the user-visible messages from the same IDs. 4. Confirm a support lead can answer: who approved, what changed, and how to revert.
Fail step 2 and you have invisible authority — the worst kind. The user experienced consequences; your team has narrative.
Pair the test with credential hygiene when the agent touches integrations: secrets stay out of prompts and repositories, rotation is scheduled, recovery is rehearsed.
Store logs where support already works — not a warehouse only engineering can query. Minimum fields per tool call: session ID, user ID, tool name, redacted input, status, timestamp, and model version. Retention long enough to cover your refund window and compliance asks.
Red-team the happy path: ask the agent to perform a denied action in staging. If it succeeds, your server enforcement failed — not the prompt.
Document the escalation phone tree the same way you document on-call for payments: who gets paged, in what timezone, with what authority to reverse a write. Agents do not sleep; your governance should not depend on someone noticing Slack in passing.
What you can prototype alone — and what stays unfinished
You can ship a read-only copilot on documented FAQs with tight context windows. That is a reasonable v1.
What stays unfinished is write access to money, identity, and customer records without governance — plus the web and app surfaces that frame the agent so users know what it can and cannot do. CLICK.BLUE builds agents and the products around them: permissions first, demo second.
If the authority inventory is drafted and the deny row is real, start a scoped prototype. If the agent is still "let it figure it out," fix the inventory before you expose customers to it.
