Product Design in the Age of Agents

On 15 July 2026, the World Health Organization brought ministers and senior representatives from 37 countries to Lisbon to discuss AI in health. WHO/Europe reported that nearly two thirds of surveyed countries were already deploying AI in diagnostics. Accountability was still looking for the meeting room. Only 8% had a health-specific AI strategy, and only 8% had liability standards defining who carries responsibility when an AI system fails.

My activity across several agent harnesses from 8 to 15 August showed how this governance deficit appears in everyday operations. At any given moment, I have between 5 and 20 agents working simultaneously on different tasks. This sounds efficient until several become confidently helpful at the same time. I reviewed 120 unique tasks. 66 were recurring automation runs, covering work such as portfolio reviews, content planning, opportunity research and community operations. The remaining 54 ranged across digital health products, clinical software, privacy, infrastructure and ordinary administration.

Across those tasks, authority repeatedly determined whether a workflow was safe to continue. The practical questions were less glamorous than the demos: who or what did the agent represent? Which organisation and patient context applied? Which repository or account could it reach? What action could it take, and whose approval was required?

I have spent more than a decade in digital health. Across my mandates, I have learned to look for the point where a useful feature touches a human consequence. Agents compress the distance between reading and acting. “Draft this” and “change the system” can now sit uncomfortably close together.

The Tenant Boundary Is a Care Boundary

Several of my tasks that week concerned multi-organisation architecture. The work included row-level database policies, organisation memberships, an active-organisation switcher, tenant-specific branding, cache clearing when a user changes workspace, and explicit organisation identifiers on clinical records.

One strand of that work gave a real-world community, shaped by weekly fixtures, movement and the social rituals of a team, its own protected space inside football.cigma.health. Membership, activity coordination and wellbeing tools had to recognise the same community boundary. Private reflection still needed a private home. I will say more on this work very soon.

These details can sound like back-office engineering, the part of digital health most likely to be ignored until it becomes front-page engineering. In practice, they answer a human question: whose world is the system operating inside right now?

A clinician may work across two facilities, while a wellbeing professional may serve several communities. Access can be valid in each setting while the current context remains wrong. A screen displaying every accessible record can pass a broad permission check and still violate a separated workspace.

That distinction matters more when an agent can act. A person may notice the wrong logo, location or patient list and pause. An automated workflow can carry the wrong context through correct-looking steps: draft against one organisation's policy, attach another's record, or place an output into the wrong queue. The model may have followed its instructions faithfully. That sentence tends to comfort only the model. The surrounding system supplied an ambiguous authority boundary.

This is why I now see tenant isolation as part of care quality. The database policy is one layer. The active workspace, user interface, cached data, tool permissions and audit record must tell the same story.

Four Questions Before an Agent Acts

My week of agent-assisted work kept returning to four questions.

Who is asking? An agent needs a verified relationship to a person, role or service. Text inside an email, webpage or document cannot grant authority by itself. If confident text were authority, every phishing email would be a board resolution. The system must know whose instruction is being carried and whether that person can authorise the proposed action.

Which workspace applies? Identity alone is too broad. The same person may hold different roles across a clinic, consultancy, community platform and personal account. Authority needs a tenant, project, patient context or data boundary.

What action is permitted? Reading, summarising, drafting, committing code, sending a message, publishing content and changing production data carry different consequences. Each step deserves its own permission. “Help with this” is convenient English and a terrible permission model.

What evidence remains? A useful record should show the request, the identity, the chosen context, the action, the result and any human approval. In healthcare, that record also needs the software version, applicable policy and clinical reviewer where the output can affect care. Without it, investigation becomes archaeology.

Authority Should Narrow Through Every Hand-off

A single agent is relatively easy to place inside a boundary. A chain is harder. One agent may gather research, another may draft, and a third may prepare publication. The combined workflow can reach a consequence that nobody explicitly approved. A chain of fast agents with diffuse responsibility can reproduce the least attractive feature of a committee at machine speed.

I saw this in the difference between content automation and publication. An agent can scan public sources, organise evidence and save a draft locally. That does not grant a right to post under my name. The agent may be tireless; my name is still mine. Publication needs the exact article, destination and a visible decision from me. The hand-off should preserve identity and context while narrowing the available actions.

The same structure applies to clinical documentation. An ambient scribe may capture a consultation, a second component may draft the note, and another may suggest a code. The clinician reviews the result before it enters care. If a future release gains the ability to place an order, that new action needs a separate privilege, validation record and regulatory assessment. Its earlier permissions cannot quietly stretch to cover the new function.

This principle gives multi-agent systems a practical shape. Every transfer should carry a trustworthy account of the initiator, tenant, permitted data, receiving agent's allowed actions and stop point. Permission can stay the same or become narrower. Expansion requires a fresh decision. That creates an inspectable route from the first request to the final consequence.

Capability Can Change Faster Than the Label

The Medicines and Healthcare products Regulatory Agency made this point tangible on 29 July. Its guidance on ambient voice technology distinguishes tools that transcribe or summarise clinical conversations for professional review from tools intended to support diagnosis or treatment, or to take automated action such as placing an order without clinician review.

One added function can move a product across a regulatory line. The interface may look almost identical. The product name may stay the same. Its authority has changed.

Release notes can be one sentence. Regulatory consequences rarely are.

I encountered that tension while reviewing XScribe, a local offline scribe I am working on validating. A locally verified build, passing tests and a reproducible software package can provide solid engineering evidence. Clinical production release asks further questions about device qualification, clinical acceptance, security, signing and accountable oversight. Software readiness and clinical readiness are separate claims, each with its own evidence.

The FDA was exploring a neighbouring issue in July when it requested patient-safety input on software functions covering healthcare administration, electronic records, data handling and limited clinical decision support. The request focused on safety practice, education and competency. Those are operational questions. They concern the people and institutions around the software as much as its code.

On 2 August, the EU AI Act reached its general application date, with later deadlines retained for specified high-risk categories. Governance now has to operate inside real workflows. A policy document cannot clear the wrong tenant from a browser cache. A committee cannot stop an unreviewed tool call at the moment of execution. Meeting minutes arrive a little late for the tool call. Governance needs mechanisms.

Governance Has to Live Where the Action Happens

For the products I work on, those mechanisms include row-level security, server-side membership checks, explicit organisation context, narrowly held credentials, action-specific approvals, immutable logs and tests that prove one tenant cannot reach another. They also include release gates that keep patient-facing functionality closed until the required evidence exists.

A July preprint called aiAuthZ tested 15 language models against agent attack scenarios. Refusal behaviour varied widely. The researchers then placed an identity-bound authorisation gateway between the model and its tools. It blocked the dangerous calls across the tested models, along with one legitimate first-time payment. Security had succeeded so thoroughly that the customer could not pay, a familiar kind of organisational victory. Good controls create friction. The design task is to place it where a mistaken action would be costly, then make legitimate approval clear and quick.

The paper is preliminary evidence, and one gateway cannot cover every route an agent might use. Its evaluation supports a practical design choice: the surrounding system should verify identity and authority before execution, so a deceived model remains contained.

What I Changed After Looking Back

I am keeping the automations. They save time and expose patterns I would otherwise miss. Automation is particularly good at finding loose ends, including those I had mentally promoted to “future work”. A portfolio scan can surface a stale branch, an exposed credential or a product absorbing effort without evidence of demand. A community process can surface participation gaps for a human organiser. A content process can collect news signals before I decide what deserves my voice.

I am also making their authority more explicit. Research can run unattended. Drafts can be prepared for review. External messages, applications, publication, production changes and clinical release remain deliberate actions with visible approval. Local verification comes before a production push. An agent working inside one project does not inherit permission across the rest of my portfolio.

This approach also changes how I think about organisational AI strategy. Leaders often begin with a catalogue of use cases. Catalogues make tidy slides. I would begin with an authority map. List the people, roles, tenants, data stores, tools and consequential actions. Decide where autonomy is welcome, where confirmation is required, and what proof must exist afterwards. Then connect the agent.

WHO's 8% figure shows how far adoption has moved ahead of that work. Healthcare has a chance to correct the sequence while many agentic systems are still young. We already understand clinical privileges, separation of duties, consent, audit trails and controlled release. The language is familiar. The implementation now has to extend those disciplines into every tool call and every automated hand-off.

My 120 tasks clarified where agents earn meaningful responsibility. The value appeared when the agent could move quickly inside a clear boundary, stop at the edge, and leave evidence that a human could inspect.

The #Ramyfications Worth Holding Onto.

Autonomy becomes useful when authority is designed.

Before an agent acts, establish who it represents, which workspace it occupies, what action it may take and what evidence it must leave behind. In digital health, those four answers belong in the product architecture, the operating model and the clinical governance record.

I will keep giving agents meaningful work. I will keep the boundaries close enough to see.