AI avatar API tools are becoming much easier to build, test, and debug in Anam Lab.

We shipped two connected updates:

1. Webhook tools now have form-based builders for headers, query params, and body params.

2. Session reports now show full tool call activity across Analytics, Overview, Transcript, and Export.

The first update makes tools easier to configure. The second makes tools easier to understand once a session has run.

That matters because tool calling is where an interactive avatar stops being a demo and starts behaving like a product. A persona that can answer from a prompt is useful. A persona that can check an order, look up CRM context, book a slot, upload knowledge, or call your internal API is much closer to what teams actually need.

AI avatar API tools let a live avatar call external systems during a conversation. In Anam, webhook tools can now be configured with form-based builders in Lab, and session reports show when each tool was called, whether it succeeded, what arguments were sent, what came back, and how long execution took.

Tool call visibility helps teams debug AI avatar sessions by showing tool activity in context. Instead of guessing why a persona answered a certain way, builders can inspect the timeline, transcript, status, args, result, error details, and execution time for each call.

Form-based webhook setup reduces the amount of raw JSON a builder has to write by hand. Headers, query params, and body params can be added as structured fields, which makes tool setup easier for product, solutions, and engineering teams working together.

Why do AI avatar API tools matter?

Tools are how a persona reaches beyond the conversation.

A support avatar may need to check order status. A sales coaching avatar may need to pull account context. A training avatar may need to score a roleplay. A product onboarding avatar may need to trigger an action inside the app.

This pattern is common across AI systems. OpenAI describes function calling as a way for models to produce structured calls to external tools. Anthropic's tool use documentation describes the same core idea: the model decides when an external function is needed, passes arguments, and uses the result in its next response.

In an avatar session, the stakes are a little higher because the user is in a live conversation. If the tool is misconfigured, the failure happens in front of them. If a tool call is slow, the session has to handle the delay. If a tool returns the wrong data, the avatar may say something that sounds confident but is based on the wrong input.

That is why tool setup and tool observability belong together.

What changed in the Lab tool editor?

Webhook tool configuration in Anam Lab now uses form-based builders for the common setup path.

Instead of writing raw JSON for every header, query parameter, or body parameter, builders can add fields in a structured form:

1. Headers get their own rows.

2. Query params get their own rows.

3. Body params get their own rows.

4. Values are easier to review before saving.

5. Teams can see the shape of the request without mentally parsing a JSON blob.

This is especially useful when product and engineering are working together.

An engineer may provide the endpoint URL, auth header, and expected body fields. A product or solutions teammate may configure the persona, write the tool description, and test the user flow. The old raw JSON path made that handoff fragile. One missing quote or misplaced comma could break the whole setup.

The new form builder removes a lot of that friction. It does not make the underlying API less powerful. It just makes the common path much easier to get right.

For more advanced setups, developers can still think in terms of API structure. The difference is that the Lab now supports the person configuring the tool, not just the person who wrote the endpoint.

What changed in session reports?

Tool calls are now visible in session reports across the places builders already review session quality.

That includes:

1. Analytics. Tool call events now appear on the session timeline, with metrics for total, succeeded, and failed calls.

2. Overview. A new Tool Calls section shows each call's status, type, args, result, error details, and execution time in collapsible rows.

3. Transcript. Tool calls now appear inline before assistant messages, so you can see when the persona invoked a tool during the conversation.

4. Export. Text exports now include tool call details with accurate timings.

This gives builders a much clearer picture of what happened during a session.

Before, debugging a tool-using persona could mean piecing together Lab output, backend logs, webhook logs, and the user's transcript. Now the report itself carries the story: what the user said, when the tool was called, what was sent, what returned, and how the avatar responded.

For teams building production interactive avatars, that is the difference between "the agent behaved strangely" and "the lookup_customer tool failed after 1.8 seconds because the auth header was missing."

How does this help teams debug personas?

Tool call visibility helps in four practical ways.

First, prompt debugging. If the persona calls the wrong tool, calls a tool too early, or misses a tool it should have used, you can see that directly in the transcript and adjust the persona instructions.

Second, API debugging. If the tool call fails, the report now gives status, args, result, error details, and execution time. That makes it easier to tell whether the issue is the prompt, the request shape, the endpoint, auth, or capacity.

Third, flow debugging. Inline tool calls show the conversation sequence. You can see whether the persona waited for the tool before answering, whether the tool result changed the response, and whether the user needed to repeat themselves.

Fourth, performance debugging. Execution time matters in a live conversation. A tool that takes five seconds may technically work and still feel broken to the user.

This is the kind of observability teams need when they move from a prototype to a real deployment. The question is no longer "can the avatar call a tool?" The question is "can we understand how the persona used tools across hundreds or thousands of sessions?"

What else changed in this release?

We also shipped a few fixes that make failure states clearer.

Connection errors. LLM URL normalization and connection error messages are clearer when custom model endpoints are misconfigured.

Avatar uploads. The avatar image upload limit now matches the real platform file limit, which helps avoid failed uploads that only appear after the user has already tried.

Session cleanup. Active sessions now clean up more reliably when the player unmounts during tab switches.

Capacity signaling. When session capacity is exhausted, the API now returns a clearer 429 response instead of a generic failure. MDN's HTTP reference describes 429 Too Many Requests as the status used when too many requests are sent in a given time, which is the right shape for capacity exhaustion.

Knowledge auth. Knowledge-upload auth and header handling are fixed for API callers.

None of these are flashy. They are the kind of product work that makes the platform easier to operate when something goes wrong.

What does this mean for builders?

The full workflow is now cleaner:

1. Configure the webhook tool in Lab with structured fields.

2. Test the persona in a real session.

3. Open the session report.

4. Inspect the timeline, tool calls, transcript, results, errors, and timings.

5. Fix the prompt, endpoint, auth, or request shape based on what actually happened.

That loop is the product.

The easier it is to move through that loop, the faster teams can build interactive AI avatars that do real work rather than only hold a conversation.

This is especially important for teams building with the AI voice agent with a face pattern, LiveKit avatar agents, VideoSDK avatar integrations, or Pipecat and Anam. In all of those systems, the avatar experience is only as good as the tools, context, and actions behind it.

For the broader product direction, we wrote about what interactive avatars mean for businesses and how conversational video AI changes the interface between users and software.

What should you try first?

Start with one tool that matters.

Good candidates:

1. A CRM lookup

2. A booking flow

3. A support-ticket lookup

4. A product-configuration check

5. A knowledge upload or search action

6. A webhook that triggers a follow-up workflow

Set it up in the new form editor, run a few sessions, then open the session reports.

Look for three things:

1. Did the persona call the right tool at the right moment?

2. Did it send the right args?

3. Did it use the result correctly in the next message?

That is where tool-using personas get better: not in the abstract, but in the report after a real conversation.

Frequently asked questions

What are AI avatar API tools?

AI avatar API tools are external actions a persona can call during a live avatar conversation. They let an avatar check systems, retrieve data, trigger workflows, or update records instead of only responding from static instructions.

What changed in the Anam Lab tool editor?

Anam Lab now has form-based builders for webhook tool headers, query params, and body params. Builders can configure common tool setups with structured fields instead of editing raw JSON by hand.

What is tool call visibility in session reports?

Tool call visibility means session reports now show tool activity across analytics, overview, transcript, and export views. Builders can inspect each call's status, type, args, result, error details, and execution time.

How does tool call visibility help with debugging?

Tool call visibility shows exactly when a persona invoked a tool and what happened next. That helps teams identify whether an issue came from the prompt, request args, endpoint, auth, response, or execution time.

Does Anam show failed tool calls?

Yes. Tool call events include success and failure status, and session reports include metrics for total, succeeded, and failed tool calls. Failed calls can also include error details for debugging.

What changed for API capacity errors?

When session capacity is exhausted, the Anam API now returns a clearer 429 response instead of a generic failure. That makes capacity issues easier to identify and handle in production apps.