When the Agent Belongs to the Team That Uses It

A senior SOC engineer at a federal managed security services provider (MSSP) supports three civilian agency clients out of the same on-prem Mattermost. Three client teams, three SIEM stacks: one runs Splunk, one runs Elastic, one runs a government-managed platform.

They all use the same @AI-Ops agent.

Every Client A query starts with a six-line paragraph explaining which Splunk indexes apply and which incident response playbook naming convention to follow. Client B analysts paste their own preamble for Elastic. When the system admin updates the shared agent’s instructions to fix one team’s complaint, the other two teams’ carefully tuned prompts stop landing cleanly.

That is not an AI quality problem. It’s an ownership problem.

Mattermost Agents v2 changes the shape of that problem. System administrators still decide which models, tools, and policies are available. But the people closest to the work can now create and manage the agents that serve their mission.

The Bottleneck Was Ownership

In many organizations, AI assistant configuration starts as a platform task. That makes sense early on. Platform admins own the system, the model provider, the security posture, and the integration boundary.

But mission context rarely lives with the platform team.

The operating team knows which Splunk index matters for Client A, which Elastic fields Client B uses, or how an incident response playbook is named. When every agent change requires a ticket to an admin without knowledge of the job, the agent starts generically and falls behind. The team works around it by pasting context into every conversation.

That workaround is expensive and fragile. The more context lives in a user’s clipboard, the less consistent the workflow becomes even within the team.

Purpose-Built Agents

In Agents v2, an agent is a workspace object that can be created, configured, and delegated from the Agents page by the end-user owners themselves. The important shift is not that there are more settings but that teams can turn their own operating knowledge into a reusable teammate.

A team-owned agent can carry the details that make the work specific:

• Instructions: The system prompt can reflect the team’s mission, terminology, escalation path, and expected answer style.
• Identity: The agent can have its own name, username, and profile image so users know exactly which workflow they are invoking.
• Access: The agent can be limited to the channels, teams, or users where it belongs.
• Delegated administration: The creator can grant edit rights to other users so the team maintains its own agent over time.
• Capabilities: Admins define the allowed models and tools; the team  chooses the right subset for the job.

For the SOC engineer, that means creating @clienta-ir-agent with a prompt grounded in Client A’s Splunk index structure and incident response conventions, restricted to ~clienta-soc. It also means creating @clientb-triage-agent with a lighter model for high-volume triage, Elastic terminology in the instructions, and access limited to ~clientb-soc.

Then the engineer delegates @clientb-triage-agent to Client B’s lead analyst. When Client B’s environment shifts, that analyst updates the agent directly.

No helpdesk ticket. No shared prompt that tries to serve everyone. No repeated preamble at the top of every thread.

Tools Scoped to the Mission

Self-service agents become much more useful when they are paired with scoped tools.

Mattermost Agents v2 builds this around the Model Context Protocol (MCP). A system administrator can configure the approved tool universe and its approval policies. From there, an agent owner can attach the tools that belong to a specific workflow.

The @clienta-ir-agent might have access to tools connected to Client A’s Splunk environment. The @clientb-triage-agent does not need to know those tools exist; it has its own set, mapped to the day-to-day triage flow for Client B.

That narrower world matters. An agent with the right instructions and the right tools is easier to reason about than a generic assistant with every capability exposed. It’s closer to a teammate with a defined role.

Critical Infrastructure: Same Pattern, Different Stakes

The same ownership problem shows up in critical infrastructure.

An OT security engineer at a regional bulk electric system transmission operator works on a six-person team responsible for both NERC CIP compliance documentation and ICS/SCADA operational security. IT provisioned one generic AI agent for the whole group.

The compliance analyst asking about CIP-010 patch management timelines and CIP-013 supply chain requirements gets the same context-free answers as the ICS engineer asking about SCADA alarm correlation. Three change requests later, the system prompt is still generic. The ICS engineer keeps receiving cloud-monitoring recommendations that have no operational path in an air-gapped environment. As a result, no one pays attention to the recommendations as most simply aren’t relevant to them.

In Agents v2, the OT security lead creates two agents instead of stretching one assistant across two jobs:

1. @cip-compliance-agent is grounded in NERC CIP language, audit cadence, and regional reliability coordinator requirements. Its tools are limited to the internal compliance document search workflow.
2. @ot-ops-agent is grounded in the team’s on-prem OT stack and ICS/SCADA terminology. It does not need external tools for every answer; for many operational questions, the value is in keeping the agent anchored to the environment the team actually runs.

Each agent is restricted to the channel where it belongs: @cip-compliance-agent to ~nerc-cip-compliance, @ot-ops-agent to ~ics-ops-security.

Compliance queries get grounded responses on the first attempt. The ICS team stops receiving irrelevant cloud-native recommendations. When new NERC CIP guidance lands, the compliance analyst updates the agent’s instructions directly.

The system admin has not lost control. They’ve just delegated it to the people closest to the problem.

Control Without a Chokepoint

Self-service doesn’t mean everyone gets unrestricted power. In Agents v2, the platform owner still sets the boundaries: available AI services, model access, tool availability, and approval policies aligned with their governance model.

What changes is where day-to-day ownership lives.

For security, defense, intelligence, and critical infrastructure teams, that distinction matters. A central admin team must own the policy boundary. The mission team must own the mission context.

This is also where sovereign deployment patterns matter. In self-hosted Mattermost environments using self-hosted model infrastructure, agent management can stay inside the facility with the rest of the collaboration workflow. Teams can create, update, and delegate agents without moving the operating model into a SaaS-only control plane.

The result is not less governance but appropriate governance that scales.

Better Agents, Fewer Workarounds

Back at the MSSP, @clienta-ir-agent and @clientb-triage-agent are now part of the way the client teams work. Client A’s questions arrive with the right Splunk assumptions already baked in. Client B’s analysts get Elastic-shaped answers without copying a preamble into every conversation.

The senior SOC engineer is no longer the queue between every prompt change and a useful agent. Client B’s lead analyst can adjust terminology when the environment changes. The platform team still sees and governs the agents through the same Mattermost deployment.

That is the mindset shift behind Self-Service Agents: not more bots for the sake of more bots, but agents owned at the level where the work actually happens.