Creating an agent

This walks through building an agent that behaves predictably. Everything here happens in the console under Agents.

1. Decide what it is for

Write the purpose in one sentence before you touch the form. "Take notes in discovery calls and record the customer's constraints" produces a different agent from "answer product questions during a service call", and the difference shows up in every later decision.

Be equally clear about what it is not for. An agent with no stated boundary tends to acquire one by accident.

2. Create it

The create form asks for a name and description, an avatar, a model, a voice, wake words and labels. If you skip the avatar, one is generated so the agent is still recognisable in a list.

For the model, either pick a platform model by provider, or select one of your own configurations from Secrets if you are running on your own model access.

A new agent starts as a draft, which means it cannot be picked for a session yet. That is the right place to work.

3. Write the instructions

The canvas is the agent's brief, written as a document rather than squeezed into a form field. It carries more weight than any other single setting, and it is worth writing at length: the role, the tone, what to ask, what to avoid, when to escalate, what "done" looks like.

Use the variable picker for anything maintained elsewhere, such as a support address or a returns window. A variable stays correct when the value changes; a pasted value does not.

4. Give it what it needs

In the configuration tab:

Entities. Which record types it can be used on. This is what decides where the agent appears, so an agent attached to nothing will never be offered to anyone.

Skills. The packaged behaviours it should have. See Skills.

Knowledge stores. What it grounds answers in. Attach what it needs and no more.

Toolkits. Which systems it can reach. Same principle: an agent with access to something it never uses is risk without benefit.

Signals. On the Signals tab, attach the definitions it should look for. An agent with none will hold a perfectly good conversation and detect nothing, which is the most common cause of an empty Signals tab.

5. Set how it behaves in a meeting

Initial meeting mode decides whether it opens silent, reactive, actively probing, or synthesising. Listen is the right default for conversations an agent should not join. Conversation is the right default for most other things.

Wake words are what get its attention while it is listening.

Voice is how it sounds when it speaks.

Calling capabilities decide whether it takes inbound calls, makes outbound ones, or both. If it should have its own number, assign one in the phone number section.

6. Decide who can use it

Attach the agent to teams. Combined with record access, this is what determines who is offered it and on what.

7. Test, then publish

Run a session with it before anyone else does. Read the transcript, check the Signals tab, and see whether the summary is the one you would have written.

Publishing is what makes the agent selectable, including on the phone. Unpublishing takes it out of circulation without deleting its history, which is usually what you want rather than deletion.

Changing an agent later

Configuration changes apply to new sessions. Past sessions keep their evidence, so changing an agent does not rewrite what already happened. Anyone with the user role can read the configuration and canvas without being able to change them, which makes the agent's brief a useful shared reference rather than a secret.