Daily operations
Ask what needs attention this morning, across every site.
How an agentic application reviews the whole operation each morning and returns the exceptions that need a decision, with the reason for each, instead of another dashboard.
Direct answer
Can software actually do this?
Dashboards show you everything and leave the judgement to you. An agentic application reviews the same data and returns only what has changed, broken or drifted since yesterday, ranked by what it will cost if ignored, with the evidence for each item. It is a short list of decisions, not a wall of numbers.
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.
- “What needs my attention this morning?”
- “What changed overnight that I would not expect?”
- “Which site is drifting, and since when?”
- “What did we say we would do yesterday that has not happened?”
- “Is anything failing quietly?”
Where this comes up
The current situation
The information is already on a screen. Nobody has time to interpret it.
Most operators have reporting. What they do not have is the fifteen minutes each morning to read six dashboards, compare them with last week, and work out which of the forty amber numbers actually matters today. So the reports get skimmed, and the problems that surface are the ones loud enough to complain.
- Slow drift is only noticed when it becomes a bad month.
- A failed integration or automation runs silently for days.
- Exceptions are found by customers rather than by the business.
- Managers spend the first hour of the day gathering rather than deciding.
- Every site is reviewed with different attention depending on who is looking.
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.
Operational state
Occupancy, bookings, jobs, stock, capacity and schedules across every site or team.
Financial movement
Payments received, failed collections, new arrears and anything unusual against the pattern.
Work in flight
Open jobs, overdue tasks, unanswered messages and commitments made yesterday.
System health
Integrations, scheduled automations and imports, including the ones that failed without telling anyone.
Yesterday for comparison
The same figures for the previous day, week and equivalent period, so a change can be recognised as a change.
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.
Take a consistent snapshot
The application reads the same defined set of operational and financial state at the same time each day, from the systems of record.
Compare against expectation
Thresholds, trends and the previous equivalent period are applied in ordinary code, so what counts as unusual is testable.
Collect the candidate exceptions
Everything outside expectation is gathered, including silent failures such as an automation that has not run.
Investigate each one
The agent reads the surrounding records to find the likely explanation rather than reporting a number that moved.
Discard what is already explained
A dip with a known cause, a planned closure or an item already being handled does not need to appear again.
Rank by consequence
Order by what it costs if nobody acts today, not by how large the number is.
State the decision needed
Each item names what a person should decide, who owns it and what evidence supports it.
Track what happens next
Items are carried forward until resolved, so the same problem cannot quietly reappear as new every morning.
Worked example
What a useful answer actually looks like.
What needs attention across all four sites this morning?
Invented figures across an invented operation, written to show the difference between a dashboard and a ranked list of decisions.
| Item | What it is | Decision needed |
|---|---|---|
| Direct debit run failed | Last night collection run processed 41 of 58 mandates. The remaining 17 returned a gateway error, not a customer decline. | Rerun the batch today. This is a system failure, not arrears, and chasing those customers would be wrong. |
| Riverside occupancy drift | Down 6% over three weeks. Move-ins are steady; move-outs have risen among units taken in the last four months. | Someone should look at why new customers are leaving early. Not urgent today, but it will not fix itself. |
| Two unanswered enquiries | Web enquiries from Saturday, neither assigned, both asking about availability at Northgate. | Assign now. Both are for a unit type currently free at that site. |
| Accounting sync stale | The nightly invoice sync last succeeded 38 hours ago. No alert was raised because it fails silently. | Fix the sync and the missing alert. Arrears figures are unreliable until it runs. |
| Short payment pattern | Three accounts have paid a pre-upgrade rate this month, all upgraded in August. | This is a billing process gap, not three separate customer problems. |
| Nothing else | Two sites, stock, staffing and scheduled work are all within expectation. | No action. Stated explicitly so silence is not ambiguous. |
Two of these items are system failures that no occupancy dashboard would have shown, and the last line matters as much as the first: a report that only ever lists problems teaches people to distrust a quiet day.
Stays in ordinary software
What must never depend on a model.
- The snapshot definition, so today and yesterday are genuinely comparable.
- Thresholds, trends and the rules that decide what is outside expectation.
- System and integration health checks, including whether a job ran at all.
- Which sites and figures each recipient may see.
- The carry-forward record of open items and their resolution.
Where reasoning earns its place
What genuinely needs judgement.
- Explaining why a number moved by reading the records behind it.
- Recognising that three separate symptoms are one underlying cause.
- Judging what would cost the most if nobody acted today.
- Discarding items that already have an owner or a known explanation.
- Writing six lines that a manager will actually read before the first meeting.
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.
The default release reads and reports. It does not rerun jobs, adjust records or contact anyone.
A site manager sees their site. A director sees the group. Scope is applied before assembly.
Every exception links to the records and figures behind it so it can be checked in seconds.
The absence of an item has to mean the check ran and passed, which makes the health of the checks part of the report.
Reversible operational actions may later be permitted individually. Money, customers and contracts stay behind approval.
Deliberate limits
What it does not do.
- It does not replace monitoring, alerting or a real incident process.
- It does not rerun failed jobs or change operational state in an early release.
- It does not contact customers or staff on its own.
- It does not set the thresholds. The business does, in code that can be tested.
- It does not become the only place the data exists.
How you know it works
The evidence to require.
- Items are compared against what an experienced manager would have flagged.
- Missed exceptions are treated as defects and traced to a rule or a context gap.
- Noise is measured. A report that is ignored after a month has failed.
- Carried-forward items are reviewed to confirm things are actually resolved.
- The checks themselves are monitored, so silence can be trusted.
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 recipient, one operation, a handful of well-understood checks.
Delivered alongside the existing routine rather than replacing it.
A daily judgement from the recipient on whether each item deserved to be there.
Checks added or removed weekly based on that feedback.
Any action capability considered only once the reporting is trusted.
Common questions
Questions about daily operations.
The questions that should be settled before anyone builds this.
We already have dashboards. Why is this different?
A dashboard presents state and leaves the interpretation to whoever is looking. This performs the interpretation: it compares against expectation, investigates the exceptions, discards what is already understood and returns a short ranked list of decisions. The dashboard remains useful for looking something up. This is for the morning.
Will it just send us more noise?
It will if you let it. The discipline is that every item must name a decision, and the recipient judges each morning whether it deserved to appear. Checks that consistently produce items nobody acts on get removed. A report that people stop reading is worse than no report, so noise is the primary failure to design against.
Can it fix the problems it finds?
Some of them, eventually, and one capability at a time. Rerunning a failed sync is reversible and low risk, so it is a reasonable early candidate. Anything touching money, customers or contracts should stay a proposal. The report earning trust comes first; acting on it is a separate decision with its own evidence.
How does it know a scheduled job did not run?
Because absence is checked explicitly. Silent failure is the most common way operational systems mislead a business, so the checks include whether each expected process ran, when it last succeeded and whether its output is plausible. That part is ordinary engineering, and it is usually the highest-value thing in the first release.
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.