Build

An agent is a saved AI configuration in a Mobius project. It has a name, instructions, a model, and optional access to actions, skills, and memory.

A project is the workspace that owns the agent, its sessions, and the related loops and data. Select the project where you want to create the agent before you begin. If Build > Agents is not available, ask a project administrator for access to create agents.

Saving the agent means you can use the same configuration again. You can chat with it in the app, connect it to a messaging channel, or add it to a loop.

Create your first agent

In the app:

1. Open Build > Agents.
2. Click Create agent.
3. Name it Support ticket reviewer.
4. Add the optional description Summarizes a pasted ticket and drafts a reply.
5. Paste the instructions below into the instructions field.
6. Leave the model and Advanced options at their defaults.
7. Click Create agent.

Mobius opens the new agent and shows a message that the agent is ready.

Use these instructions for the first test:

Review support-ticket text pasted into chat. Return three headings: Problem, Missing information, and Draft reply. Do not invent missing details. Do not call actions, send the reply, or change a ticket.

This tells the agent what input it will receive, the required format, and what it must not do.

What controls an agent

An agent's page brings its settings and connections together.

An action performs one named operation. A toolkit groups actions so you can assign them together. Assigning a toolkit does not bypass the access rules for the project or the connected service. Project permissions and the access granted by the connected service still apply.

See Toolkits and skills for the full distinction.

Keep each agent focused

Give an agent one responsibility that you can describe in a sentence. A support triage agent might summarize a ticket and draft a reply. A reporting agent might read monitoring results and prepare a daily summary.

Split the work into separate agents when:

• the tasks need different instructions;
• the tasks need access to different external systems; or
• keeping the access boundaries separate makes them easier to review.

This makes each agent easier to test. It also makes its access easier to review.

Three ways to use an agent

A session holds the agent's conversation. A run shows how one loop moved through its steps. A loop that uses an agent creates both records because they answer different questions.

Test before connecting other systems

The new agent page opens in Configure mode. To test it:

1. Open Sessions and click New chat session.

2. Paste this message:

   Ticket 4182: Pat cannot open the monthly report. The page says “Access denied.” The ticket does not say which report or when the problem began.

3. Send the message and wait for the reply to finish.

4. Confirm that the reply has Problem, Missing information, and Draft reply headings.

5. Confirm that the draft asks for the missing report and timing details. It should not claim that the issue was fixed or that a reply was sent.

6. Return to Sessions and open the most recent row. The transcript should show your message and the reply, with no action call between them.

This is a useful first test because the ticket text is supplied in the message. The agent does not need a toolkit or a connection to a ticket system.

Connect messaging or add the agent to a loop after this direct test behaves as expected. Those workflows are covered in Agent messaging and Loops.

Change an existing agent

Open the agent in Configure mode and click Edit to change its name, description, instructions, model, skills, or toolkits. Click Save when you are done.

The edit keeps the same agent ID. It does not rewrite earlier session transcripts or completed runs. Future turns use the agent's current saved configuration. An open session can use the new configuration on its next turn, but its older messages remain in the transcript. For a clean comparison, use New chat session after each instruction change and send the same test message again.

Edit the existing agent when you are improving the same responsibility, including an intentional toolkit change. Create a different agent when a new responsibility or access boundary should remain separate.

Choose where information belongs

For example, a note about how one customer prefers reports may belong in agent memory. The current list of that customer's servers belongs in a table or the system that owns the list.

Pause or remove an agent

Open the Agent actions menu on the agent page and choose Disable agent to stop it from receiving new work or appearing as an available routing choice. You can enable it again later. Existing sessions remain records; inspect active runs separately because disabling an agent is not a recovery control for work already in progress.

Choose Delete agent from the same menu only when you want to remove it from the project. The confirmation explains that loops which refer to it need another agent before they can run. Mobius retains past message history for attribution, but the deleted agent is no longer available for new work.

Exact API fields are in the interactive API reference. Terminal commands are in the CLI command reference.

Next

• Write more detailed instructions with agent definitions.
• Learn how conversations are stored in agent sessions.
• Add controlled capabilities with toolkits and skills.
• Use the agent in a repeatable process with loops.