Governed chat invocation
Aniya, now in Slack and Microsoft Teams.
Chat agents are table stakes. Governed chat execution is the part teams still need to get right.
Agents in chat are no longer novel.
Microsoft has Copilot agents in Teams and Microsoft 365. Slack has Agentforce. Atlassian has Rovo in Slack and Teams. Google Chat has Gemini. The market has already agreed that work starts in the places people talk.
So "we put an agent in Slack" is not the interesting claim.
The real question is what happens after someone types @anyia or runs /anyia.
Is the request tied to the human who made it? Does it inherit their scopes, approved integrations, and policy gates? Does it route to the right existing agent? If no agent exists, can the successful workflow become one? Can the reply land back in the same thread with audit intact?
That is the layer we built Aniya chat invocation around.
What Shipped
You can now invoke Telara agents directly from Slack or Microsoft Teams with @anyia, /anyia, or a direct message where the provider supports it. Discord is next, using the same shared command-ingress contract rather than a separate one-off bot model.
When Aniya is invoked, Telara verifies the provider request, resolves the installation to a tenant, maps the external chat user to a Telara user, and runs the agent on behalf of that human. Not as a shared bot with broad credentials. As the mapped user, under their scopes and policy.
The Detail That Matters
A chat message is not enough context for governed execution. It has to become a typed request from a known actor, in a known workspace, from a known channel or conversation, against a known set of tools and permissions.
Before any tool runs, Telara checks the request as the mapped human user.
Platform admin status in Slack or Teams does not grant Telara permissions by itself. The chat platform is the entry point. It is not the identity provider, authorization layer, or audit system.
How Routing Works
Once identity and scope are resolved, Telara searches for the right execution path in order:
Explicit agent reference
User-scoped agents
Channel-bound team or project agents
Tenant agents
On-behalf-of manual execution when no agent matches
If no agent matches, Aniya can still run the workflow on behalf of the user. When that fallback succeeds, Telara uses the prompt, scope, tools, and successful steps to recommend turning the path into a durable agent.
What Is Governed From Chat
Identity
The agent acts as the mapped Telara user behind the chat account, not as a shared bot identity.
Scope
Channel and conversation bindings map Slack channels or Teams teams to a Telara team, project, or tenant scope.
Tool Allowlist
Scoped tool generation happens at session start, so disallowed actions never appear in the agent tool list.
Approval Gates
When an action needs approval, the gate lands in the thread where the request started and execution holds until approval or rejection.
Audit
Every invocation records the human, channel, selected agent, tools used, approval chain, and final result.
Why This Matters Now
The problem is not whether companies will have agents in chat. They already do. The problem is whether those agents become another shadow automation surface: hard to scope, hard to route, hard to audit, and disconnected from the rest of the agent lifecycle.
Aniya's chat surface uses the same governance model as the rest of Telara. There is no looser "chat mode." The bot is a thin ingress over the same control plane: identity, scope, allowlist, approval, audit, and agent lifecycle.
Check The Rollout Gap
If you are evaluating whether your current agent setup is ready for org-wide use, run the Agent Rollout Gap Checker. Chat entrypoints are one of the gaps it checks, because chat without identity mapping, scope binding, dedupe, approvals, and audit is not ready for production execution.