Account context
Ask for the whole client picture before the call, not after it.
How an agentic application assembles a complete, permission-aware client summary from records, messages, payments and open work so staff stop reconstructing it manually.
Direct answer
Can software actually do this?
An agentic application can produce a client summary because it reads the record, the agreement, the open work, the money and the recent correspondence together, then writes what a colleague would need to know before speaking to that customer. It is not a saved report. It is assembled for the question being asked, and every statement points back to the record it came from.
How it gets asked
The request, in the words people already use.
These are not prompts to be learned. They are the sentences a manager says to a colleague, which is the standard an agentic application should meet.
- “Summarise this client before I call them.”
- “What is the current situation with this account?”
- “What has changed on this account since we last spoke?”
- “Is there anything I should not raise with this customer today?”
- “Give me the same summary for every account I am seeing this week.”
Where this comes up
The current situation
Everybody rebuilds the same picture, slightly differently.
Before a call, someone opens the CRM, searches their inbox, checks whether the last invoice was paid, asks a colleague whether the complaint was resolved and forms a view. It takes ten minutes and it is done again by the next person tomorrow. The picture is never wrong exactly, but it is inconsistent, and the parts nobody thought to check are the parts that cause the awkward moment.
- Preparation time is repeated by every person who touches the account.
- Important context lives in one inbox and is invisible to everyone else.
- Customers are asked for information the business already holds.
- Handovers lose the reasoning behind the last decision.
- Nobody notices the pattern across accounts because each is read alone.
What the answer depends on
The application has to read all of this, not one system.
The reason this work stays manual is rarely difficulty. It is that the answer lives in several places and only a person currently holds them together.
The customer record
Identity, contacts, sites, agreements, tier and the relationships that decide who may be told what.
Open work
Jobs, tickets, orders, bookings or cases that are live right now, with their state and who owns them.
Financial position
Current balance, recent invoices, payment behaviour and anything in dispute, quoted from the ledger.
Correspondence
Recent messages, call notes and commitments made, restricted to the channels and mailboxes the business has agreed to include.
History worth remembering
Previous escalations, agreed exceptions and preferences that were true last year and are still true now.
What the application does
The job, step by step.
Each step is either ordinary application code or a bounded piece of reasoning. Knowing which is which is the difference between a system you can operate and a demonstration.
Resolve the account and the asker
The application confirms which customer is meant, and what this person is permitted to see about them.
Decide what the summary is for
A renewal conversation, a complaint, a collections call and a first meeting need different context. The purpose shapes the assembly.
Gather across systems
Records, open work, ledger position and recent correspondence are read through typed capabilities, each honouring its own permission model.
Select rather than concatenate
The agent chooses what is material for this purpose and leaves out the rest. A summary that includes everything is another thing to read.
State the position plainly
What the relationship is, what is open, what is owed, what was last promised and by whom.
Surface the things that would embarrass you
An unresolved complaint, an unanswered message, a promise made and missed, a renewal that has quietly lapsed.
Cite every claim
Each statement links to the invoice, ticket, note or message behind it, so a person can check anything that matters before they repeat it.
Prepare, do not send
Any suggested follow-up is a draft. External communication remains a human decision unless a specific low-risk case has earned automation.
Worked example
What a useful answer actually looks like.
Summarise the Trenton Joinery account before my call at two.
An invented account, written to show the shape and the citation habit of a useful summary rather than to describe any real customer.
| Section | What the summary says | Where it came from |
|---|---|---|
| Relationship | Trade account since March 2023. Two sites. Main contact Ellen Voss, accounts handled separately by Priya Raman. | Customer record, contact roles |
| Open work | Two orders in progress. Order 8812 is four days past its promised date because a supplier part slipped. | Order system, supplier note 2 September |
| Money | Balance £2,140. Invoice 7731 is 12 days overdue. Everything before it was paid on time for eleven months. | Accounting ledger |
| Last commitment | On 28 August we told Ellen the late order would be delivered this week. That has not been confirmed to her since. | Call note, outbound email thread |
| Raise carefully | The overdue invoice covers the late order. Chasing payment before confirming delivery is likely to escalate. | Agent reasoning across the two threads above |
| Suggested opening | Confirm the delivery date first, then ask whether the invoice can be settled once the order lands. | Draft only. Not sent. |
The value is in the fifth line. Every system involved was individually correct, and only reading them together showed that the overdue invoice and the late delivery are the same conversation.
Stays in ordinary software
What must never depend on a model.
- Which records and mailboxes are in scope for this person and this account.
- The balance, the invoice dates and the state of every open job.
- Data retention and what may be surfaced from historic correspondence.
- The customer relationships that decide who may be told what.
- The audit record of what was assembled and shown.
Where reasoning earns its place
What genuinely needs judgement.
- Judging what is material for this particular conversation.
- Connecting a late delivery in one system to an overdue invoice in another.
- Noticing a commitment that was made and never followed up.
- Writing the position in a few sentences a colleague can actually use.
- Saying plainly when the records do not contain enough to answer.
Control boundary
What keeps this safe to run.
Autonomy is not a setting. It is the sum of the scope, the tools and the approvals the application has been designed to enforce.
Context is gathered as the person asking, not as a service account with access to everything.
A summary without citations is a rumour. Each line carries the record it rests on.
Which mailboxes and channels may be read is an explicit, reviewable decision, not a side effect of an integration.
Suggested follow-ups are prepared for a person. Sending is a separate, deliberate act.
Anything the system retains about a customer can be inspected, corrected and deleted.
Deliberate limits
What it does not do.
- It does not invent history. If the record is silent, the summary says so.
- It does not expose correspondence a person could not have opened themselves.
- It does not send anything to the customer.
- It does not become the record. The CRM and the ledger remain the source of truth.
- It does not keep an unbounded profile of a customer because it might be useful later.
How you know it works
The evidence to require.
- A colleague who knows the account reads the summary and agrees with it.
- Every cited claim can be traced to the underlying record.
- Missing information is reported as missing rather than smoothed over.
- Preparation time before calls falls measurably, and the calls do not get worse.
- Errors are collected as a dataset and used to fix context assembly, not the wording.
A sensible first release
Narrow enough to trust, complete enough to be useful.
The first version should be able to fail without costing anything, while still producing an answer somebody would miss if it disappeared.
One team, one customer type, one purpose such as pre-call preparation.
A short list of the systems that may be read, agreed with whoever owns the data.
Citations required from the first day, not added later.
A comparison against how the same people prepare today.
Expansion to other purposes only when the summaries are trusted without checking.
Common questions
Questions about account context.
The questions that should be settled before anyone builds this.
Is this just a CRM record with an AI wrapper on it?
No. A CRM record shows what is stored about a customer. This answers what somebody needs to know before a specific conversation, which usually means combining the record with the ledger, open work and recent correspondence, and then leaving most of it out. The selection is the useful part.
Will it read our email?
Only the mailboxes and channels you explicitly include, under the permissions of the person asking, and with a retention position you have agreed. Blanket access to a company inbox is a design decision with real consequences, so it should be made deliberately and reviewed, not inherited from an integration default.
What stops it from making something up?
Citations, and a scope narrow enough to check. Every statement links to the record behind it, and the system is expected to say when the answer is not in the data. In practice, the fastest way to lose trust is a confident summary of an account with thin records, so an early release should report gaps rather than fill them.
Can it summarise every account before a week of meetings?
Yes, and that is often where the time actually goes. The same capability runs across a list of accounts and returns the same structured summary for each. Cost and latency then matter, which is one reason model routing and context size are engineering decisions rather than an afterthought.
Related use cases
How Codemind builds it
Start with the job
Bring the request, the systems and the person who does it today.
You do not need a specification. We will separate what belongs in ordinary software from what genuinely needs reasoning, and describe a first release that can prove itself.