ElevenAgents Architect: designing and correcting voice agents with tests and drafts

ElevenAgents Architect is an assistant to build, analyze and improve voice agents, working on configurations, conversations and tests. It is not the voice that responds directly to the customer: it helps the team understand and modify the system that handles those conversations.

ElevenLabs presented it on 6 October 2026 in alpha, with gradual distribution. Documentation describes free access during the alpha, indicated up to October 2026: is not a promise of permanent gratuity. Changes are prepared in unpublished drafts, to be verified before activation. ElevenLabs Announcement and documentation Architect.

For an SME using AI telephony, the novelty is mainly about maintenance. When an assistant misunderstands a request, the problem may depend on the prompt, instrument, path, or knowledge base. Architect can help investigate; the team still has to decide which fix is appropriate and try it before it reaches customers.

What problem does Architect try to solve?

A voice agent consists of several parts: instructions, voice, tools, documents, paths, and controls. When a call goes wrong, listening to the result is not enough to pinpoint the cause. A wrong answer may arise from an outdated source; a missing appointment may depend on the calendar; a failed transfer may be a route problem.

Architect is described as an assistant capable of reading the operational context and proposing interventions on prompt, workflow, tool, knowledge base and guardrail. His role is to make the construction and diagnosis work more accessible, according to the documented functions. No Giallo tests or independent results on the quality of corrections are presented here. Declared functions.

The Guide to voice AI for companies helps to distinguish these levels. A natural voice is only part of the experience. The system must understand the task, use correct data, comply with permissions and give the customer a recognizable outcome. Maintenance concerns all of these steps.

How do drafts and publication work?

Documentation indicates that proposed changes are retained in unpublished drafts. This creates a review space between team request and active agent behavior. However, it should not be read as a guarantee that any proposed correction is safe or correct. The draft must be understood and tested. Documented change management.

Before publishing it is useful to compare previous and new configuration. The team should know what problem they want to solve, what components change, and what conversations might be affected by it. A change to the seemingly local prompt can alter an already working path, especially when introducing new priorities or exceptions.

It is preferable to correct an identified problem at a time when this makes the comparison clearer. Changing instructions, tools, and documents together can improve a test but make it difficult to understand why. A brief note with hypothesized cause, intervention and test performed helps to maintain the service even when another person intervenes.

What data to avoid in the chat with Architect?

Conversations with Architect are not covered by Zero Retention Mode, according to documentation. Therefore, it should not be assumed that the setting adopted for other parts of the service will automatically extend to this assistant. It is appropriate to avoid personal or sensitive data in messages and to check current conditions prior to use. Limitation on conservation.

To describe an error, an anonymized reconstruction is often enough: caller request, expected action, result obtained and component involved. You don't always need to paste the full conversation with your name, phone, and practice details. Minimization should be a team operating rule, not an improvised decision to every problem.

Access to conversations and tests should also be checked. Maintainers of the system may need different technical information from those visible to those managing the customer. Before the pilot you need to understand which people can consult that data and with what purpose. A maintenance assistant does not make the responsibilities on the analyzed content irrelevant.

How to distinguish the mistakes of a phone call?

The table proposes a method of diagnosis. Avoid using “the wrong model” as a universal explanation. An incorrect parameter and an obsolete document require different corrections. The analysis should retain only the information necessary to distinguish these cases.

The AI voice errors They also often concern the design of the service. If the system does not know what to do when the customer changes request, it is not enough to replace a sentence in the prompt. You have to decide whether to cancel a proposal, confirm a data or transfer the conversation. Architect can assist the work, but the business rule must exist.

Hypothetical scenario: a help center corrects reservations

Let's imagine a help center that uses a voice agent to book surgeries. Staff note that some requests are associated with the wrong service. Before changing the prompt, it collects anonymized examples and checks whether the calendar categories are understandable and consistent with customer language.

Architect can be used to examine configuration and testing and prepare a correction proposal. The draft is tested with clear, ambiguous and correct requests mid-conversation. The team controls both the spoken text and the category actually sent to the instrument. A reassuring response is not enough if the recorded intervention remains wrong.

This is a hypothetical scenario. It does not indicate a customer's results or a measured reduction in errors. The outcome to be asked of the pilot is a demonstrable correction on the observed problem, along with the absence of regressions in the paths already approved. The publication comes after the revision, with the possibility of retrieving the previous configuration.

Hypothetical scenario: a distributor improves the transition to staff

Consider a distributor who uses voice to read the status of orders. The client may, however, request a commercial change that the agent is not authorized to perform. The observed problem is an unclear transfer: the customer does not know if he is talking to a person or if the request is only registered.

The team defines the expected behavior first. If an operator is available, the path transfers the call with an essential summary; otherwise it collects a request below. Architect can help edit messages and workflows in draft, but does not invent the real availability of staff or decide business commitments.

This case is also hypothetical. The test must include absence of operators, insistent request and incomplete data. The correct result is an understandable and workable outcome. The guide to AI switchboard for phone calls shows why the human passage is part of the service and not a detail to be added after the choice of voice.

What tests to repeat after a correction?

Open the tab to verify a draft Architect

Identify the problem and preserve the previous behaviour. Test the change on the case that caused the error, similar cases and paths already working. Check responses, tools, writes and handoffs. Publish only after review, and prepare a procedure for returning to the previously approved configuration.

Tests should not be composed only of ideal demands. We need missing information, noise, changes of mind, extraneous requests and unavailable services. The decision to stop must also be assessed. An agent who insists when he cannot complete the task can increase frustration and risk.

The theme links to Aqua and the errors of the agents in production: Behavior analysis requires observations and criteria, not just a judgment on the elegance of the answer. Simulations help to explore paths, but need to be accompanied by checks on the integrated system that performs the operations.

Is technical monitoring enough to tell if the agent is working?

No. A service can respond correctly at a technical level and leave the customer without a solution. The team must observe outcome of the task, human steps and requests remaining incomplete. Tool errors are part of the picture; service quality also includes correct information and promises consistent with business rules.

The new Make Event subscriptions offer an example of a channel to report events of an automation platform. They are not an Architect function and are not presented as a ready integration. Conceptual linkage is the need to bring a signal to a person who can act.

Any major correction should have a manager and a follow-up check. If a document, calendar, or external service changes, some tests must be repeated even without changing the prompt. The agent depends on the operating context: keeping only the instructions means controlling one part of the system and ignoring the others.

Does free Alpha mean zero cost of the project?

No. Free access during the alpha covers the conditions indicated for Architect, does not eliminate the cost of the agent in operation, telephony, integration or revision work. The duration and subsequent conditions must be verified on the official pages and in the account. A future list is not hired here. Alpha conditions.

Distribution is gradual: the announcement does not prove that every Italian account already has access. If the function is not present, the project must be able to continue with known configuration and testing procedures. Basing all maintenance on unverified access creates an avoidable dependency.

For a comparison of levels, Amazon Nova Sonic is a voice model to be integrated, while Architect assists in the construction and maintenance of agents in the ElevenLabs environment. The choice should be made on the complete work cycle and service requirements, without treating products with different roles as perfect substitutes.

Where is he wrong using an assistant to correct other agents?

The first mistake is publishing a proposal because the explanation seems convincing. The second is to share sensitive data in the chat assuming the coverage of Zero Retention Mode. The third is correcting a symptom without checking source and tools. The fourth is to test only the case that failed, forgetting the paths already working.

Another mistake is leaving the software with an undefined service decision. If the company has not established when to accept a request or how to handle a complaint, the maintenance assistant cannot turn that ambiguity into a legitimate rule. The person responsible must decide; the system can help translate the decision into configuration and testing.

Finally, the correction must remain understandable. A team that accumulates contradictory instructions can lose control of behavior. When an exception repeats, it is useful to ask whether an explicit path, a better source, or a narrower tool is needed, instead of adding another sentence to the prompt.

How to make maintenance readable over time?

The team should keep an essential record of the changes: observed problem, updated component, test cases and publication decision. There's no need to turn it into an indiscriminate archive of conversations. The track must help a colleague understand what has changed and what behavior to control if the problem returns.

When a correction is withdrawn, the pattern should be kept visible. Otherwise a similar proposal can be published again without recalling the limit that has already emerged. Drafts allow revision, but service memory still requires a team procedure. The software does not replace this organizational responsibility.

Those receiving transfers should also contribute to reporting. It can recognize missing information or misunderstood promises that do not emerge from the technical log alone. A structured note, lacking excess data, makes that match usable in the next voice path revision.

How to start with a call that created a problem?

Choose a representative conversation, reconstruct it without unnecessary data, and define the correct outcome. Identifies the part of the system that might have caused the problem. Then prepare a draft, compare the change and test the path along with the related cases.

The useful deliverable is a revised correction with evidence, not a new unexplainable configuration. Those who manage the service must know what changes, why it changes and how to understand if the problem returns. This method remains valid even when alpha tools and conditions evolve.

If your phone assistant answers but leaves unsolved requests, work on AI Agents Giallo can start from those conversations. The goal is to connect diagnoses, rules, tools and tests in a service that the team knows how to maintain and the customer can understand.