MODULE 5 · DEEP-DIVE
Chat Agents Deep-Dive
The reusable unit of value in Quick. Anatomy, lifecycle, audit-defensible patterns, and Alex's three Chat Agents.
🤖 Why Build a Chat Agent?
The Rule of Three
If you've typed the same prompt three times, it should become a saved Chat Agent. Typing "summarize this week's reconciliation breaks by severity and draft commentary" for the fourth Monday in a row is a signal, not a habit.
Alex Tan's Monday Morning — Without & With a Chat Agent
| Without a Chat Agent | With a Chat Agent |
|---|
| Consistency | Re-types the prompt from memory, wording drifts week to week | Same prompt, same structure, every run |
| Time | 10–15 minutes rebuilding context each Monday | One click, output in under a minute |
| Team reuse | Nobody else has "the good prompt" | Shared with the team, same quality for everyone |
| Auditability | No record of what was asked or why | Agent definition is the record |
Four Reasons a Saved Agent Beats an Ad-Hoc Prompt
♻️
Reusable
Write it once. Run it every close cycle. Your teammate runs it too. Zero re-typing.
📐
Consistent
Every break memo gets the same severity logic. Predictability the internal auditor will appreciate.
📌
Version-able
Edit the agent → next conversation picks up the new version. Change-history lives on the agent, not in a chat scroll.
🤝
Share-able
Build it once. Share with Viewer or Owner permission. Your whole team benefits from a workflow only you had figured out.
🧬 Anatomy of a Chat Agent
The Five Parts at a Glance
- Persona — who the agent is and how it should sound (e.g., "a precise, plain-spoken Finance Compliance coordinator")
- Goal & Instructions — what it's for and the rules it must follow
- Knowledge — which Space/documents it's allowed to draw from
- Actions — any tools or MCP connectors it can call
- Suggested Prompts — the one-click starters shown to users
The Secret 6th Element — Reference Documents
What persona/instructions can't guarantee — reference documents can. Telling an agent to "follow the expense policy" is not the same as grounding it in the actual expense policy document. Reference documents are what prevent hallucinated thresholds and invented approval limits.
The 80/20 — What Actually Determines Whether Your Agent Works
①
Specificity of the Goal
"Summarize this week's status" is vague — output will drift. "Produce a brief with these 5 named sections in this order" is specific — output is reliable.
②
Tight Knowledge Source
"Use the Space" is loose. "Focus on this week's reconciliation export and the NCR-style break register" is tight. Tight sources prevent hallucination from stale files.
③
Clear Guardrails
"Never invent a number" and "Never recommend approval" are explicit prohibitions. The agent respects them — but only if you write them down.
Four Ways to Create a Chat Agent
- From a Template — fastest start for a common pattern
- Natural Language — describe what you want in plain English Recommended
- From a Chat Conversation — turn a good ad-hoc exchange into a saved agent
- Blank Builder (Manual) — full manual control over every field
🔄 The Chat Agent Lifecycle
6 Stages
✍️
1 · Draft
Write the natural-language brief covering all 5 parts.
🧪
2 · Test
Run it against real examples before sharing — including edge cases and adversarial inputs.
💾
3 · Save & Share
Publish to the team with the right permission level.
🚀
4 · Use
Production use via suggested prompts, @-mention, or a schedule.
🔁
5 · Iterate
Fix a miss by editing the agent definition, not by re-prompting in chat.
📤
6 · Deprecate
Retire it cleanly when the process it supports changes or ends.
Three Failure Modes Across the Lifecycle
The Set-and-Forget Trap: Built once, never revisited as policy changes — the agent quietly drifts out of compliance with the current procedure.
The Scope Creep Spiral: One agent slowly absorbs more and more responsibilities until nobody can predict what it will do — split it back into focused agents.
The Ghost Agent: Built, shared once, then abandoned. Nobody uses it, nobody maintains it, and it still shows up in search results confusing new team members.
🛡️ Best Practices & Patterns
The Audit-Defensibility Pattern — Finance's "Pattern 5"
Baking audit requirements directly into the agent definition:
- Named output sections — every memo produced has the same shape, every time. Audit-defensible by construction.
- Numbers traceable to tool calls — no invented figures. Every number either cites a source record or flags
[NEED: data].
- Flag-only, never auto-act — the agent never clears a break, approves a credit memo, or releases a payment on its own. A human stays in the loop.
- Cited source documents — every policy statement traces back to a named procedure document and section.
- Redacted personnel/client data — output never surfaces PII beyond what's needed for the task.
7 Do's — The Patterns That Work
- Write the goal as if explaining it to a new analyst on their first day
- Name every output section explicitly
- State guardrails as "never" statements, not hopes
- Ground every factual claim in an uploaded document
- Default sharing permission to Viewer
- Test against at least one adversarial input before sharing
- Review and re-test after any linked policy document changes
6 Don'ts — The Patterns That Fail
- Don't let one agent cover multiple unrelated jobs
- Don't rely on "use good judgment" as a guardrail
- Don't skip testing because "it worked in one chat"
- Don't grant Owner permission by default
- Don't let an agent auto-approve, auto-close, or auto-send anything financial
- Don't forget to deprecate an agent when its process retires
⚓ Alex's Three Chat Agents
📋 Weekly Close Status Agent — Alex's Monday Workhorse
Brief: "Summarize this week's month-end close progress from the reconciliation tracker and the close calendar. Produce a status brief with sections: Completed, In Progress, At Risk, Blockers. Never invent a completion percentage — cite the tracker directly."
Guardrails: Flags any account reconciled but not yet reviewed; never marks an item "complete" unless the tracker says so.
🚨 Reconciliation Break Triage Agent — The Lab 1B Build
Brief: "Review today's reconciliation export. Classify each break by type and severity. Draft a disposition note per break citing the source line. Never clear a break — flag for preparer review only."
Guardrails: Flag-only; every classification cites the specific transaction line; severity thresholds pulled from the reconciliation procedure document, never estimated.
📄 Credit Memo Section Reviewer — Alex's Cross-Discipline Helper
Brief: "Review the financial ratios section of this credit memo against our credit policy thresholds. Flag any ratio outside policy range and cite the relevant policy clause. Never recommend approval or decline — flag for the credit officer only."
Guardrails: Never issues an approval/decline recommendation; cites the specific policy clause for every flag.
What These Three Agents Have in Common
📐
Named output sections
Every agent produces the same shape every time. Audit-defensible by construction.
🔢
Numbers traceable to source
No invented data. Every number either cites a record or flags [NEED: data].
🚫
Flag-only, never auto-act
None of them clear breaks, approve memos, or release payments on their own.
🧠
One job each
Status, Triage, Review. No multi-purpose agents. Clean scope, predictable behaviour.