AI agent standards are evolving. What should businesses do now?

The development: a focus on interoperable, secure agents

On 17 February 2026, NIST announced its AI Agent Standards Initiative, focused on supporting interoperable and secure AI agents. The initiative page describes work around standards, protocols and agent security and identity. This is a dated industry development, not a newly issued universal certification for business agents. [1][2]

For a buyer considering an AI receptionist, customer-service assistant or workflow agent, the practical implication is to ask for evidence of control and interoperability. That is our interpretation of the direction of travel, not a NIST product endorsement or a claim that any particular vendor has met a new mandatory standard. This article was researched on 18 October 2026; procurement teams should recheck official publications when making a decision.

Why a good conversation is only part of the product

A voice demonstration may show fluent speech and quick answers. A deployed assistant also needs to handle unavailable tools, uncertain information, identity checks, interruptions and requests beyond its authority. The risk changes when an assistant moves from explaining an appointment policy to actually changing a booking.

NIST’s Generative AI Profile provides a broader resource for identifying and managing risks associated with generative AI. It complements the AI Risk Management Framework rather than serving as a ready-made acceptance test for your particular voice agent. [3] Translate the relevant concerns into observable behaviour in your own service environment.

Define three boundaries: knowledge, identity and action

Start with knowledge. Identify approved sources for business hours, service descriptions, prices and escalation procedures. Assign an owner and review date to each source. The agent should have a response for missing or conflicting information, such as offering a human follow-up, instead of filling gaps with an unsupported promise.

Next, define identity. Decide which questions can be answered anonymously and which require verified customer access. A caller knowing a name or reference number should not automatically receive sensitive records. Verification must be implemented in the surrounding application and tools, with a documented recovery path when verification fails.

Finally, define action. List every permitted operation, the systems it touches, the fields it can change and the approvals it requires. A read-only availability lookup and a cancellation are different permissions. Where a caller must confirm an action, make the confirmation refer to the exact booking or change being requested.

Build an evaluation set from real service scenarios

Create a small but varied test library before selecting a final voice or model. Include normal enquiries, ambiguous names, background noise, silence, mid-sentence interruptions and different accents used by your actual customers. Use invented personal data or appropriately protected test records. Do not assume a single clean studio recording represents real telephone traffic.

Add tool failure cases: the calendar times out, the customer database returns no record, the booking succeeds but the confirmation call fails, or the user changes their mind after an action. Review both the spoken response and the system state. A reassuring message is not a pass when the underlying booking is wrong.

Set acceptance thresholds by use case. Track task completion, unsupported claims, incorrect actions, failed transfers and response delay. Report the sample size and test conditions. Avoid one broad accuracy percentage that hides severe failures inside a large number of simple questions.

Make human handoff usable

A handoff is a workflow, not just the sentence ‘I will transfer you.’ Define the destination, operating hours, timeout behaviour and information passed to the receiving team. Include a fallback when nobody answers. The caller should understand whether they are connected, waiting or leaving a request for later follow-up.

Decide which information belongs in a handoff summary and which should be omitted. A service agent may need the caller’s stated problem and a verified reference, but not an unrestricted transcript. Make transcript access and retention deliberate choices, and review recording, disclosure and privacy requirements for the jurisdictions and use cases involved.

Pilot with limits and preserve the evidence

Begin with one bounded workflow, such as service enquiries followed by a callback request. Use limited access and a clear owner who can pause the agent. Monitor a representative sample of interactions, correct knowledge problems, and rerun the tests after changing prompts, tools, models or policies.

Ask suppliers how you can export configuration, test cases, logs and business data. Understand which integrations are portable and which require rebuilding. Evolving standards make these procurement questions useful today even when a final standard does not yet answer every detail.

Evo builds AI voice assistants and agents around business services and workflows. A readiness engagement can turn a broad idea into a defined scope, permission model, evaluation set and handoff process. For workflows spanning several systems, pair that work with software integration planning so that conversation quality and operational correctness are assessed together.

Frequently asked questions