Planning your ALIVE Agent Studio character
Prepare the role, character look and approved knowledge for one agent that can appear in different places.
Define whom the character helps
A character begins with a useful role. Before choosing a look in the ALIVE Agent Studio, write down the visitor it serves and the question it should help resolve. A website guide might explain an approved service page and point to the appropriate next step. A teaching character might explain a topic supplied by its owner. These are examples for a planning brief, not statements that a particular deployment is already complete. Naming the role helps you evaluate the experience without relying on how expressive the character looks. The public introduction should also make clear that the speaker is an AI.
Keep the character's personality separate from its authority. Warm language can make a visitor comfortable, but it should not imply that the agent is a human employee or a licensed professional. Decide how it introduces itself, how it describes its job and how it responds when it lacks a source. If a person must review a consequential choice, preserve that boundary in the brief. A character can present the same approved information in a friendly way while still saying that it cannot make a commitment on the owner's behalf. That is a content decision to settle before polishing animation.
Choose a character look for the setting
NetShow's live looks include ASCII, sketch, SVG, toon and rigged character forms. The character is a look worn by the same host, rather than a reason to create another voice session or a disconnected player. The default direction is a character, not an imitation human face. Think about the space available on a phone, the page beside the host and the visitor's device. A small expressive form can make the role clear without taking over the reading area. Review the proposed appearance in context, where visitors actually read the page and choose their next step.
A human or photoreal appearance is an optional path, not the default expectation for a NetShow character. Do not assume that a particular advanced look is available, included or approved for every site. Ask which choices the current Studio supports for your intended setup and which depend on a paid lane or further work. Keep a visual preference in the brief, but avoid making it an unsupported delivery promise. The practical goal is a recognizable host that remains understandable at the size and bandwidth of the visitor's device, with a clear relationship between its expression, voice and role.
Give the host approved knowledge and tools
The character needs something useful to say. Prepare a short set of source pages, approved questions and answers, and examples of questions it should return to a person. A drawing or animation may help explain those sources, but it does not make an unsupported statement true. When the host presents a card, page or visual explanation, check that the underlying information is current. This is especially important when a character moves around the page and directs attention to a section. The visual explanation should help the visitor understand the approved material rather than suggest that an unverified action has happened.
The platform's host skills include drawing on the stage, moving around the page, showing content and driving the site through its existing tools. Their presence in the platform does not mean every action is authorized in a particular deployment. Define the permitted navigation and distinguish pointing from filling a form or submitting it. Camera use needs the visitor's consent when seeing something would help. Ask what information is needed and keep unrelated private material out of the frame. Preparing these boundaries before a demonstration gives you a better way to evaluate whether the host's skills fit the intended role.
Review the complete experience
A visitor should meet one host with one voice, not a collection of separate controls and demonstrations. NetShow's proxy path supplies the host voice. The visible introduction can arrive with the page, while browser sound restrictions may delay speech until the visitor's first interaction. Review what happens in that first moment and what remains readable if sound is unavailable. Then watch how the character responds to an ordinary question and an unclear question. A smooth animation is useful only when the visitor understands the answer, the role and the next step. Keep the experience clear on a small screen.
Explore the public Studio before deciding what to build. You can prepare a role brief and visual direction without treating a preview as a finished deployment. Generating your own avatar belongs to the signed-in Studio path; ordinary exploration should remain available to a stranger. When discussing the build, ask about current supported looks, the approved voice path, source knowledge, tool permissions and where a person takes over. Keep requests for future features clearly separate from the accepted scope. The result you are planning is one useful AI character connected to real work, not an appearance that makes unsupported promises about what the system can do. Keep the role brief beside the visual reference so the character remains tied to its approved purpose as the appearance changes.
Questions about this guide
What can I plan in the ALIVE Agent Studio?
A role and character look for an AI agent, connected to its knowledge, voice and tools. Explore the Studio publicly; generating your own avatar uses the signed-in Studio path.
Which voice does the NetShow host use?
The host uses the NetShow proxy voice path. Mrs. NetShow uses marin and Mr. NetShow uses cedar. Browser sound restrictions can delay speech until the first interaction.
Does the host need camera access?
Only when seeing would help and the visitor consents. Keep unrelated private information out of view; reading the site does not require camera access.