Leave The Default Agent Alone And Write Role Limits

Small product teams keep adding chat seats when the real leak is a blurry job. One tab writes docs. The same tab also “helps” with billing copy. A week later nobody can say which voice invented a feature the roadmap never shipped. OtterMind only helps if that blur becomes a written role, not another chat tab.

In our desk the failure shows up as a polite paragraph that cannot be defended in review. The first version looks useful. Then someone opens the spec. A button appears that the build does not have. The file is unreadable as a handoff. That wasted afternoon goes to apologies and re-work, not to shipping. A configurable Agent exists to stop that mix, not to sound smarter in the sidebar.

A Job Description Beats A Smarter Chat Tab

An Agent in this workspace is a reusable role. It receives the ask, then works from a default model, a Role, and the Skills bound to it. That is closer to a job card than to a personality. If the card says “docs only, no invented controls,” the output has a place to fail. If the card says “be brilliant,” the output has nowhere to fail except taste.

Teams that skip the card keep one default voice for every mess. Docs, outreach, and internal notes start to sound like the same intern. Reviewers then argue tone instead of checking the spec.

One-Off Questions Do Not Need A New Agent

Not every prompt deserves a new role. A one-line lookup, a simple rewrite, or a task with unclear file rights is a poor reason to click New Agent. Roles pay off when the same responsibility comes back: product docs, release notes, a weekly research digest. If the job will not return, keep it on a light task and move on.

This is also where small teams waste seats. They clone Agents for mood. They now have six names and one real job. The list becomes a costume rack.

Create The Role Before Binding Extra Skills

Ottermind puts Agents in the left sidebar. Each card shows the name, a short description, the default model, bound Skills, and actions. New Agent asks for Name, Description, Default model, and Role, then optional Skills. Name and default model are required. Role is the sentence that says who this worker is, how it should work, and where it must stop.

Write the Role first. Bind Skills second. A Skill is a capability pack. If you bind packs before the job is clear, the Agent will pick a tool because the tool is there, not because the task needs it. Ottermind will not save a team that skips this order.

• Name the repeating job, not the mood of the week.
• Write a Role a contractor could fail against.
• Bind only the Skills that job needs, then click Save.

Write Boundaries Not A Hero Persona

A usable Role reads like a policy. One good pattern: you write product documentation, you keep steps short and checkable, and you do not invent a control the spec does not name. A weak pattern: you are the strongest assistant and can do anything. The weak line feels motivating. It also licenses a second feature that never shipped.

Read the Role aloud. If a contractor could not fail the job against that sentence, the sentence is decoration. Rewrite until a reviewer can point at the line and reject the draft.

Default Model Changes Speed Cost And Ceiling

Default model is not a mascot. It changes how fast the Agent works, how much a run costs, and where the work hits a ceiling. The public docs are honest about flux: available models and their blurbs can change, so the live dropdown is the source of truth. Pick the model for the job you named, then leave it until the job changes.

Do not rebuild the Role every time a new model label appears. That habit turns the sidebar into a showroom. The Role stays. The model is a setting. If two people on the same team pick different models for the same docs job, write that fight down. Either the Role is unclear or the job is actually two jobs.

A release-note Agent and a public-docs Agent can share a folder and still need two Roles. One may summarize diffs. The other may refuse to invent UI. Mixing them is how a changelog grows a fake toggle.

Save After The Role Can Be Read Aloud

Edit lives on the card or in the lower-right menu. You can change name, description, default model, Role, and Skills. Save applies the change. If you edit and walk away, the next task still runs the old job. Small teams lose an hour here and blame the model.

After Save, start a real task with that Agent. Do not trust the card text alone. If the first output invents a setting, the Role is still too soft or a Skill is doing work you did not ask for.

Too Many Skills Make The Extra Pack Fire

An Agent can only use Skills that are bound and enabled. Bind too many, and an extra pack can fire. Bind too few, and a real job comes back incomplete. After you remove a Skill, that capability is gone. If the task still needs it, the result fails in a boring way: missing steps, missing files, a half-built note. Reviewers then spend another hour hunting a toggle that the Role never allowed.

High-permission Skills do not belong on a docs Agent. If a pack can call outside services or touch files, keep it off the role that drafts public copy. Confirm the source and the data scope before a sensitive folder goes anywhere near that card. A public help article and a customer contract should never share the same Agent card.

Feedback Should Name The Miss And The Redo

When the output is wrong, do not send “make it better.” Check the task text, the Role, the default model, and the bound Skills. Then say what is wrong, what the correct bar is, and whether you want a revision or a redo. That note is the cheapest training the Agent will get. Paste the rejected sentence next to the spec line it violated so the next run has a concrete miss, not a mood.

A discarded draft should leave a reason. “Invented a settings toggle” is a reason. “Did not like the vibe” is not. The second reason teaches nothing and invites the same miss next week.

Keep Sensitive Files Off The Wrong Agent

Customer lists, contracts, and keys do not belong on an unreviewed pack or on a general role. If the job needs those files, make a narrower Agent, bind only the Skill that job needs, and keep the default system Agent out of that folder. The docs are blunt: the default Agent is a base role. Do not delete it. Do not load it with every experiment. Create a new Agent when the job is specialized.

Teams that route specialized docs through OtterMind ai still keep a human gate. Role text is a brake, not a lawyer.

Keep One Job Description Per Agent

Ottermind is useful when each Agent can be read as a job. One role. One default model. A short Skills list. A Save you actually clicked. The default Agent stays boring on purpose.

If the sidebar is a pile of nicknames, you do not have a workspace yet. You have chat with extra labels. Write the boundary, bind only what the job needs, and let the next review fail against a sentence a contractor could use.