Reference

An agent's definition is its job description: the instructions, which AI model it uses, how long one turn may take, and which tools and skills it has.

The agent is the worker. The definition is how that worker currently does the job. Keeping those separate is what lets Scout get steadily better over months without ever losing its history.

The parts

Writing the instructions

This is the part that decides whether the agent is any good, and it's the part people rush.

Write it like you're briefing someone on their first morning. Four things:

What it's for. One sentence. "You sort incoming tickets for the Northwind IT service desk."

What good looks like. Be specific about shape. "Reply with a category, an urgency from 1 to 4, and a two-sentence summary. No preamble."

What to never do. This is the one people skip and then regret. "Never promise a client a timeline. Never say a problem is fixed unless you've confirmed it. Never guess at a licence count."

What to do when unsure. "If the ticket is ambiguous, say so and mark it for a human rather than guessing."

Keep the standing instructions about the enduring role. Put per-task procedures in skills and provider capabilities in the agent's tool grant, so the instructions stay short enough that you'll actually maintain them.

Picking a model

The model is the AI itself: Claude, GPT, Gemini, and so on. Different ones cost different amounts and are better at different things.

You don't need to have an opinion on day one. Start with the default, get the instructions right, and only then try a different model on the same task and compare. Changing the model and the instructions at the same time tells you nothing about which change helped.

Higher reasoning levels think harder and cost more. Worth it for judgment calls; wasted on "reformat this list".

The agent stays; the definition changes

You'll rewrite instructions many times. That doesn't create a new agent, and it doesn't throw away sessions, memory, or history.

Tuning it

Change one thing at a time. This is the entire method and it's easy to skip.

1. Give it a real task in Chat.
2. Read what it actually did, including which tools it reached for.
3. Change one thing: a sentence of instruction, one tool, the model.
4. Run the same task again and compare.

The session is a full record of what the agent saw and did, which is what makes this comparison possible at all. Change three things at once and you've learned nothing.

One source of truth

Mobius stores the agent definition. Direct conversations, routines, messaging, and API invocations all read the same configuration, so an operator can see what will run without reconstructing precedence across several systems.

Products embedding Mobius can reconcile the same agent through its assign-once external_ref and update the stored configuration during provisioning or deployment. Invocation requests carry conversation input, not a second definition.

A model picker is the narrow exception: it may set a model_override when it creates a session. That changes the model for the conversation without copying or replacing the agent's instructions, tools, skills, memory policy, reasoning effort, or timeout. The Agent configuration API guide documents that boundary.

In the app

Open Build > Agents, pick an agent, then Configure.

Start with clear instructions and no tools. Have one real conversation. Add the first tool only when something the agent genuinely needed was missing.

Next

• Understand the worker itself in agents.
• Add capability with tools and skills.
• See what a conversation remembers in agent sessions.
• Configure agents from code with the Agent configuration API guide.