Cities Run AI Agents on Messy Data. So Can You.

By Lazar Milicevic · Published October 15, 2026 · 9 min read

You have a recurring business decision, like which invoices to chase or which leads to follow up, and the information behind it lives in three or four tools that don't talk to each other. NVIDIA just published a rundown of how European cities handle the same problem at municipal scale. The pattern underneath is small enough to copy this week, and none of it requires a GPU.

What the cities actually built (and what NVIDIA didn't tell us)

On October 14, 2026, NVIDIA published a post saying cities and partners across EMEA use its accelerated computing to build physical AI agents and digital twins for urban operations (NVIDIA blog). The decisions on the table are ordinary and expensive: when to repair a road, how to use energy more efficiently. Projects span Belgium, Finland, France, Italy, the Netherlands, Poland, Sweden and the U.K., among other places, built with local software partners.

A digital twin, in this context, is a software replica of a real system, such as a road network or a building portfolio, that an agent can read from and test decisions against.

The most concrete example is France. The Department of Côte-d'Or, Akila and ThinkDeep built operations agents that combine sensor, infrastructure and historical data in a sovereign digital twin. The agents cover more than 500 public buildings, supporting energy, compliance, safety and climate resilience. NVIDIA reports that document search time fell from weeks to minutes and total operating costs fell 10%, with a 30% target at scale.

Here's the caveat you should carry through the rest of this post: those numbers are vendor-reported. The announcement gives no baseline, no time period and no methodology, and I found no independent verification. Blockchain.News makes the same point, noting these are outcomes stated in the announcement, not verified municipal performance data. The same goes for the SNCF Gares&Connexions figures NVIDIA cites from an earlier blueprint post (100% on-time preventive maintenance completion, 50% less downtime and response time, 20% less energy use). Treat all of it as a direction signal, not proof.

Also worth stating plainly: nothing in these sources says the cities' data was "messy," and nothing says the AI was the easy part. That framing is my own opinion as someone who builds these systems. What the sources do say is that the agents combine data from several kinds of sources (sensors, infrastructure records, history), which is the part that transfers to your business.

The pattern: connect, model, recommend

Strip away the branding and the city deployments follow three steps. NVIDIA's own smart city blueprint describes almost exactly this: build a digital twin, train and fine-tune models, then deploy real-time agents that alert, summarize and query camera and sensor data (NVIDIA blueprint post). Translated for a small team:

1. Connect the sources. An agent that can't see your data is a chatbot. The first job is getting payment status, client email and accounting records into one readable place.
2. Model how the work flows. This is your version of the digital twin: a current, trustworthy picture of your operation that the agent reads from.
3. Let the agent recommend; a human approves exceptions. The agent proposes, the team decides.

Notice that the model is step three. In my view, two thirds of the pattern is plumbing and structure, which is the part I find myself spending the most time on when I build AI automations for small teams.

Step one: audit the decision, not the tools

Before building anything, pick one recurring decision and count its inputs. This takes twenty minutes and no software.

Good candidates:

• Which leads get a follow-up today
• Which invoices get chased
• Which jobs get scheduled first

For the decision you pick, write down every source of information you consult. Count them. If it's three or more, living in different tools, you've found an automation candidate, because the decision is only as slow as your slowest lookup.

Here's what that looks like for a small invoicing business hand-typing around 200 invoices a week (an illustrative scenario with round numbers, not a client case):

decision: "Which clients get a payment reminder today?"
sources:
  - name: accounting system
    holds: invoice amount, due date, paid/unpaid
  - name: email
    holds: client replies, promises to pay, disputes
  - name: payment processor
    holds: pending transfers not yet reconciled
  - name: CRM / spreadsheet
    holds: client tier, payment history, contact preference
source_count: 4
slowest_lookup: email   # unstructured, needs reading

Four sources, one of them unstructured. Nobody can answer "which clients are about to pay late" quickly because answering requires four lookups and a human reading email. A city has the same problem with road sensors, maintenance schedules and energy meters. Same shape, different scale.

Step two: build your own digital twin

The digital twin is the part of this story most worth stealing, and it's the least glamorous. For a small business it doesn't mean a 3D simulation. It means one structured, current view of the entities your decisions depend on.

For the invoicing example, that's a table where each row is an open invoice with everything the decision needs:

from dataclasses import dataclass
from datetime import date

@dataclass
class InvoiceState:
    invoice_id: str
    client_id: str
    amount: float
    due_date: date
    paid: bool
    payment_pending: bool        # from payment processor
    last_client_reply: str | None  # summarized from email
    client_disputes: bool
    past_late_count: int         # from history
    preferred_contact: str       # "email" | "phone"

def days_overdue(inv: InvoiceState, today: date) -> int:
    return max(0, (today - inv.due_date).days)

Each field maps to one of the four sources above. The sync job that fills this table is boring: pull from accounting, pull from the payment processor, extract a one-line email summary, join on client ID. But it is the whole game. If this table is wrong, everything downstream is wrong.

This is also why data quality matters more than model quality. If your records are inconsistent, a smarter model just gives you confident wrong answers faster. Fix the picture first, then add the agent. A few checks worth running on any new twin before an agent touches it:

• Freshness: every row carries a synced_at timestamp; stale rows get flagged, not trusted.
• Reconciliation: totals in the twin match totals in the source system, checked daily.
• Null handling: missing fields are explicit (None), never silently defaulted to "fine."

Step three: write the spec in plain sentences, then let the agent propose

Once the twin exists, the spec for your agent is the rule you already use in your head, written down. Ask yourself how you decide and write it in plain English:

Remind a client today if:
- the invoice is more than 3 days overdue, AND
- no payment is pending, AND
- the client has not disputed it, AND
- we have not already reminded them in the last 7 days.

Escalate to me (do not auto-send) if:
- the client has a late history of 3 or more, OR
- the amount is above my usual threshold, OR
- the last email from the client mentions a problem.

That text is the system prompt's decision policy and the guardrail in one. The agent's job is to apply it to every row of the twin and return a proposal list, not to act:

def propose_actions(twin: list[InvoiceState], today: date) -> dict:
    proposals = {"send_reminder": [], "needs_human": []}
    for inv in twin:
        if inv.paid or inv.payment_pending or inv.client_disputes:
            continue
        if days_overdue(inv, today) <= 3:
            continue
        if inv.past_late_count >= 3 or inv.amount > ESCALATION_THRESHOLD:
            proposals["needs_human"].append(inv.invoice_id)
        else:
            proposals["send_reminder"].append(inv.invoice_id)
    return proposals

In practice an LLM sits on top of this for the fuzzy parts, like reading the last email and judging whether it signals a dispute. The deterministic rules handle everything that can be deterministic. The model handles interpretation and drafting. Whatever lands in needs_human goes to a chat message or an inbox review queue with the draft attached.

The integration is the real work. The model on top is the easy part.

Keep a human on the exceptions

This is where small teams get burned. They hand an agent the keys on day one, it makes one bad call on a real client, and they pull the plug on the whole project. The cities are doing the sensible thing: NVIDIA's description is of agents that help teams make decisions and anticipate maintenance needs, not agents that act unsupervised.

A rollout sequence worth following:

1. Shadow mode (week 1-2): the agent proposes, nothing is sent. You compare its list to what you would have done.
2. Approve-all mode: every action needs a click. You measure how often you override it.
3. Auto-approve the boring middle: low-value, low-risk, no-history cases go through automatically. Everything else still queues for you.
4. Review the overrides weekly. Each override is either a rule you forgot to write down or a data error in the twin. Fix it at the source.

Keep an audit log of every proposal, every approval and every override. It's your evidence for deciding whether to widen the agent's authority, and it's what lets you explain a bad call instead of guessing at it.

Do you need NVIDIA-class hardware?

No, and the sources make clear why the city stack looks the way it does. Cities are running video analysis, sensor streams and simulations. NVIDIA names Cosmos models and its Metropolis blueprint for video search and summarization, Nemotron models for reasoning agents, and Omniverse libraries for digital twins. System builders such as Cisco, Dell Technologies, HPE, Lenovo and Supermicro package this into locally operated "AI factories" so cities keep control of their data, models and operations (Europe Says).

That data-control motivation is worth borrowing as a principle, even though you won't buy the hardware. Decide where your client data goes before you wire an agent to it, and prefer setups where you control credentials, scopes and logs.

A small business making decisions from email, a CRM and accounting data needs reliable connections between those tools. That means API access, a scheduled sync, a clean table and a model API call. Most automations of this kind don't require a GPU cluster, so don't let enterprise hardware headlines convince you the problem is out of reach.

Where this fits at bizflowai.io

At bizflowai.io, the focus is practical AI automation for solopreneurs and small teams. The first two steps of this pattern are the natural place to start: connecting email, CRM and accounting data into one structured view, then writing the decision rules in plain language so an agent can propose actions while the owner approves the exceptions. Invoicing follow-up and lead triage are good first candidates, because the decision is repetitive, the inputs are scattered across three or more tools, and a wrong call is cheap to catch in a review queue.

What to do this week

• Pick one recurring decision and list every source you consult for it.
• If you count three or more sources in different tools, that's your candidate.
• Write the rule you already use, in plain sentences, including the exceptions you'd want to see yourself.
• Build the single table that holds everything the decision needs, and reconcile it against the source systems before adding any agent.
• Run the agent in shadow mode and compare its proposals to your own judgment.

If you want the long version of the cities' story, read NVIDIA's original post with the vendor lens on. If you want the part that helps your business, it's the sequence above: fix the picture first, then add the agent.

Want more like this?

I write about practical AI automation for solopreneurs and small teams.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milićević, senior engineer building practical AI automation.

Visit bizflowai.io to learn more.