An assistant needs a name and a boundary

What we found in the news

A February 2026 NIST draft concept paper (opens in a new tab) explored identity and authorization for software and AI agents. One of its questions was:

“How might an agent convey the intent of its actions?”

— National Institute of Standards and Technology

This was an initial project concept, not a final standard or product certification. It makes a practical issue visible: when an assistant can act, people need to understand which assistant is involved, whose authority it uses, and what it proposes to change.

Why this matters to us

A helpful suggestion and a completed action have different consequences. Comparing room options is one task; changing a booking is another.

Imagine a coordinator considering a request to move a community activity to a more suitable time. A participant points to their preferred option on a paper grid while a colleague reviews a proposed change on a laptop.

In this imagined workflow, an assistant can prepare the proposal. The coordinator retains the final confirmation after checking the room, the time, and who needs to know.

At genus, we want the boundary between preparation and action to remain clear. Fluency in a conversation does not establish authority to alter someone’s plans.

Know what is acting on whose behalf

An assistant should be distinguishable from the person using it. A friendly name may help people recognize the interface, but operational identity and permissions need a more precise arrangement.

Ask the responsible technical team how the service identifies the assistant and connects its permitted actions to an authorized request. Staff need an understandable account of that arrangement.

For our imagined room change, the relevant authority comes from the coordinator’s role and the agreed workflow. It should not depend on the assistant sounding confident that the change is sensible.

Confirm which systems and information the task actually needs. Preparing a room proposal should not quietly grant unrelated access to participant records or other services.

Make the proposed change reviewable

Before confirmation, show the details that matter to the person deciding: the current arrangement, the proposed replacement, and the people or resources affected.

A general prompt asking whether to continue is insufficient if the reviewer cannot see what continuing will do.

In the example, the coordinator checks availability and confirms that the new time fits the participant’s request. They also need to know whether the action updates a booking only or sends messages as well.

Give the reviewer a way to correct or decline the proposal. Human review is useful when the person can understand and influence the action, with enough time and information to make the decision.

Keep the action understandable afterward

Once an action occurs, the team needs a reliable way to determine what changed and through which authorized process.

Ask what records the actual service retains and who can inspect them. The organization should be able to distinguish the assistant’s proposal, the person’s approval, and the resulting action where those steps are part of the workflow.

Plan how unexpected behavior is raised and who can restrict the assistant’s access while it is investigated. Those are service and technical responsibilities to establish before widening use.

In our imagined room change, a participant who receives an incorrect time needs a reachable person who can trace and correct the arrangement. An explanation that the assistant did it does not resolve their problem.

What this means for the people you serve

People should be able to understand when a tool is offering information and when an authorized change affects their plans. They deserve a clear confirmation and a route to someone who can explain or correct what happened. Responsibility should remain visible after the conversational screen closes.

The genus connection

Today, genus partner-portal workflows use configured roles and bounded assistance, with staff review in supported preparation workflows. The actions available in a particular setup must be confirmed.

A proposed assistant-driven workflow would need that same clarity of purpose, permission, and review, with its technical controls demonstrated. We would begin with a specific task and a person accountable for the outcome before considering any expansion of authority.

One question to take away

Before this assistant acts, can the reviewer see exactly what will change and whose authority permits it?