The wind brings a branch down across the street, and the facility’s internet goes with it.

In room 14, Mrs Wu sits up and swings her legs out of bed. The bed sensor notices. Twenty metres away, a small box in the comms cupboard decides this is worth an alert, and Priya’s handset buzzes.

She’s there before Mrs Wu has found her slippers. Nobody in the building knows the internet is down, and that’s the point.

Why boundaries come first

Most architecture diagrams start with services. This one starts with lines on a map, because the non-negotiables are about where things happen:

• Identifiable health data stays in Australia.
• Only de-identified metrics go regional.
• Night alerting runs on site and works offline.

Get the lines right and many later decisions follow from them. Get them wrong and no amount of security tooling will fix it.

The map

flowchart TB
    subgraph REG["Regional plane · not designed yet"]
        RM[("De-identified<br/>quality metrics")]
    end
    subgraph AU["Country plane · Australia"]
        subgraph AUE["Australia East · as-built sandbox"]
            PLAT["Landing zone, shared platform,<br/>cloud agents, care data,<br/>logs and audit"]
        end
        subgraph AUSE["Australia Southeast · recovery option"]
            DR["Landing-zone infrastructure only"]
        end
        subgraph FAC["Facility edge · target"]
            NWE["Night Watch:<br/>triage, local alerts,<br/>local event store"]
        end
    end
    subgraph TEN["Microsoft tenant services"]
        IDS["Staff and family identity"]
        A365["Agent 365 registry<br/>logging off"]
    end

    NWE -. "pseudonymised events" .-> PLAT
    PLAT -. "de-identified export only" .-> RM
    PLAT -. "recovery inside Australia" .-> DR
    PLAT --- IDS
    PLAT -. "inventory only, no care content" .-> A365

What’s allowed across each line

This table matters more than the diagram. Each boundary has an explicit allowed list and an explicit never list.

Boundary 1: the facility

Night Watch is the only agent that lives on site. Its triage engine, sensor broker, alert tiers, acknowledgement and escalation, nurse-call adapter and an append-only event log all run in the building.

Two rules make this work:

1. Nothing that alerting needs crosses the line. If the cloud vanished, alerting wouldn’t notice.
2. Only pseudonymised events go up. The cloud uses them to start a draft incident note for an RN, to hold routine family updates, and to inform shift planning. Raw sensor streams stay on site.

Boundary 2: the country

Everything else runs in a single Azure region, Australia East. That covers every resource and every log destination: there’s no cross-region peering, no replication and no log export.

Some less obvious choices also come from this boundary:

• AI models use regional deployments in Australia East, not the global or multi-region “data zone” options, so prompts and responses are processed in-country.
• Family accounts sit in an identity tenant hosted in Australia.
• Network flow logs stay in-region, because network telemetry can include IP metadata about the people using the service.

The line people forget

Some Microsoft services live at the tenant level rather than in a region. Agent 365, which provides a registry and governance for agents, stores its activity data in the tenant’s geography rather than in Australia East.

The design therefore registers each agent’s existence (name, ID, sponsor) and keeps Agent 365 activity logging switched off until a privacy review approves it. That’s an uncomfortable trade-off: it gives up useful telemetry to stay on the right side of the line.

Boundary 3: the region

The brief wants a group-wide view of quality across countries. The only thing allowed to feed it is de-identified data, exported from each country’s record after a de-identification step that is reviewed against Australian law.

This plane is Target, and not designed yet. No regional hub and no cross-border connection exist, and that’s deliberate. Adding one will be a separate, explicit decision.

When Australia East has a bad day

This is where the boundaries get expensive. The obvious recovery site is Australia Southeast, but:

• The FHIR service used for the care record isn’t offered in Australia Southeast (checked 9 Nov 2026).
• The Care Record design also lists Speech, Azure OpenAI and Agent Service as not available there. I need to re-check this before writing the disaster-recovery decision.

Like-for-like failover inside Australia isn’t possible today, and failover outside Australia is never allowed. The working approach is to fail closed and degrade manually:

• The operator’s clinical system stays the system of record, so the FHIR copy can be rebuilt from it.
• Cloud agents pause, or tell people that staff will follow up.
• Caregivers keep documenting in the clinical system directly.
• Night Watch carries on, because it never depended on the cloud.

Honest gaps

That’s Part 1. Next, in Part 2, we go down a layer: an AI landing zone, three kinds of identity, and why “private by default” is harder than it sounds.

Grace opens the family portal and types: “Did Mum eat dinner? And is the doctor worried about her blood pressure?”

The reply comes back in seconds. Mum had most of her dinner and enjoyed the soup. The second question, it says, is one for the care team, and a nurse will call Grace tomorrow morning.

Grace doesn’t see what happened behind that answer. The agent was never able to read the blood-pressure notes in the first place.

That one exchange contains most of the architecture. This post shows the rest on one page.

The one-sentence architecture

The model drafts. Rules decide. People confirm.

A language model is very good at writing, summarising and translating, but it isn’t a reliable place to keep a decision. So in this design, the decisions live elsewhere:

• Consent, entitlement and disclosure (who may see what) are code.
• Claim rules and pricing are code.
• Roster rules (24/7 registered nurse cover, skill mix, award rules) are a solver plus an independent checker.
• Alert triage for Night Watch is deterministic.

The model writes the words. It never makes the decision.

Seven principles

1. The model drafts, deterministic services decide, people confirm. The decision logic is rules and code, not prompts.
2. The confirmed record is a hard boundary. Drafts never go into the care record. Billing and Family Communication only read confirmed entries.
3. Agents hold no data roles. Resident data is reached through a gateway, with one route and one permission for each consumer.
4. Identity is proven, not chosen. Every agent has its own least-privilege identity, and every human decision records who made it.
5. One data plane per country. Identifiable data stays in Australia East. A regional plane only ever receives de-identified metrics.
6. Safety-critical alerting is local. Night Watch runs on site and doesn’t depend on the cloud.
7. The simpler service wins unless a written decision record shows why something newer fits better.

The picture

Boxes are capabilities, not servers. Dashed boxes are designs that haven’t been built yet.

flowchart TB
    subgraph People
        STAFF["Staff<br/>caregivers, RNs, managers, billing"]
        FAM["Families and supporters"]
    end
    FD["Secure front door<br/>Front Door + WAF, staff and family sign-in"]
    subgraph Agents["Cloud agents · Australia East"]
        CR["Care Record"]
        BI["Billing"]
        SP["Shift Planning"]
        FC["Family Communication"]
    end
    subgraph Support["What the agents lean on"]
        AI["AI runtime<br/>Foundry, regional model"]
        DET["Rules, not prompts<br/>consent, entitlement,<br/>claim rules, roster solver"]
        GW["Care Record Gateway"]
    end
    FHIR[("FHIR care record<br/>synthetic data")]
    NW["Night Watch<br/>on site, local alerting"]
    REG[("Regional view<br/>de-identified only")]

    STAFF --> FD
    FAM --> FD
    FD --> Agents
    Agents --> AI
    Agents --> DET
    Agents --> GW --> FHIR
    NW -- "alerts to handsets" --> STAFF
    NW -. "pseudonymised events" .-> Agents
    FHIR -. "de-identified export" .-> REG

    classDef target stroke-dasharray: 5 5
    class BI,SP,NW,REG target

Two decisions worth unpacking

1. Where does a decision live?

In Grace’s case, a deterministic entitlement service checked who she is, which resident she’s linked to and which kinds of information she may see. The model only got to write the reply after that check.

2. How does an agent reach resident data?

The Family Communication agent holds a permission called CareRecord.Read.Shareable. It doesn’t hold a FHIR role at all. Even if someone tricked the model into asking for blood-pressure notes, the gateway route it can call simply doesn’t return them.

Agents don’t talk to each other

You might expect five agents to call each other directly. They don’t. They share facts, not permissions:

• Care Record is the source of facts. Billing and Family Communication only see entries a caregiver has confirmed.
• Night Watch events become draft incident notes for an RN to review, and they put a hold on routine family messages, so Grace doesn’t get a cheerful “quiet night” update after a fall.
• Shift Planning publishes the approved roster, which tells Night Watch whose handset to alert.

This means one agent can never gain another agent’s data rights by asking it for something.

What’s built, and what isn’t

Next: three boundaries (facility, country and region) and what’s allowed to cross each one.

Tomás has finished his last round. Before he can go home, he has to write up the night: who slept, who didn’t, who needed help to the bathroom at 2 a.m.

Down the corridor, Priya is reading through an incident note. Was it a fall or a slip? Does it need reporting? The decision is hers.

Two hours away, Grace’s phone buzzes: “How was Mum’s night?” Nobody has had time to answer yet.

None of these three people needs an AI to decide anything for them. What they need is time. That’s the problem this series is about.

The brief, in three numbers

The case study describes a regional aged-care operator. I’ve called it Zava Care Group.

Caregivers are scarce, and every hour spent on paperwork comes out of hands-on care. Night incidents, family enquiries and rejected insurance claims add to the load.

The brief asks for agentic AI that hands that time back to care. It also sets firm limits on what the agents may do.

Five agents, five jobs

The operator asked for five agents. Each one gets a fixed autonomy level, which says how far it can go before a person steps in:

• L2 (recommend): the agent proposes, and a person approves before anything happens.
• L3 (act with oversight): the agent carries out the task within set rules, and a person confirms the result, handles exceptions and responds to escalations.

Notice that nothing goes above L3. The brief says “no automated care decisions”, and that caps every agent. Agents can draft, prepare, recommend and alert. Clinical judgement stays with qualified staff.

Shift Planning sits one step lower than the rest. A wrong roster affects staffing standards and labour rules and is hard to undo, so a manager signs it off before it takes effect.

Targets, not results

The brief comes with ambitious numbers. Here they are, labelled honestly:

The Australian twist

The brief describes an Asian operator, but I’ve framed the design around Australian regulation. A real regulatory setting turns vague requirements into concrete ones. It also changes how some of the targets read.

The growth targets need an Australian translation. The latest StewartBrown survey coverage reported residential occupancy near capacity (Inside Ageing, 21 July 2026). So “15% more residents” doesn’t translate directly. Capacity and agency hours avoided, or growth in home care, are better measures. The brief’s USD 40 million revenue target also needs a local value model; it isn’t an Australian forecast.

Care minutes are measured on paid hours. Each resident’s funding class comes with daily care-minute targets, set in the Aged Care Rules 2025 (compilation in force from 1 October 2026). These are counted against paid worked hours, so saving documentation time doesn’t raise a facility’s reported care minutes. What it does is put more of those paid minutes into direct care, which matters more.

Billing value is mostly about accuracy. For residential care, the money is in getting each resident’s funding classification right and on time (Department of Health, 24 July 2026). Fewer rejections matter more for home care and private fees.

Regulation shapes the design. For example, privacy-policy transparency rules for automated decision-making commence on 10 December 2026 (OAIC, 30 September 2026). Any agent that does something “substantially and directly related” to a significant decision needs to be disclosed.

The rules that can’t be broken

These are the non-negotiables. Every later post comes back to them.

1. No automated care decisions. Agents draft, recommend or alert. People confirm, approve, certify or respond.
2. Resident health records stay in Australia. Identifiable data never leaves the country.
3. Only de-identified quality metrics go regional. A group-wide view of quality, without names.
4. Night Watch alerting runs on-site and keeps working offline. A falls alert can’t depend on an internet connection.

The brief also requires these controls, which the design treats as equally firm:

• Consent before sensitive data is processed, with a non-AI fallback.
• Alert-accuracy thresholds that Night Watch must meet before it goes live.
• A family disclosure policy that is enforced in code, outside the language model.
• A billing audit trail, with a person certifying each claim.

What’s in scope, and what isn’t

Still open

I’ll be honest about what’s not settled yet:

• The value model. The business case for an Australian operator isn’t written yet, so there are no baselines.
• How to restate “more residents served” for a market that’s already nearly full.
• The final success measures for a pilot. The candidates are documentation minutes per resident-day, billing exception rate, night alert-to-acknowledgement time, staff turnover and occupancy. None has a baseline yet.

Next: the whole system on one page, and the principle that holds it together: the model drafts, rules decide, people confirm.