Before You Put an AI Agent in Slack or Teams, Give It an Identity, a Budget, and a Stop Button

The Operator Signal

AI agents are moving out of isolated chat windows and into the places where work begins: Slack channels, Microsoft Teams discussions, development environments, and shared company systems.

That makes agents easier to use—but also easier to trigger without enough context or oversight.

Recent product releases show the emerging operating model. Agents can now accept assignments from team conversations, work asynchronously, use connected systems, create business artifacts, and return completed work for review. The better implementations also expose the agent’s identity, preserve the source conversation, respect existing permissions, support spending limits, and require human approval before consequential changes take effect.

For a small or midsize business, the decision is not simply whether to “use AI agents.” It is whether to let an agent cross the boundary between suggesting work and changing the business’s systems of record.

The practical answer is to start with a supervised agent that:

• Works from a narrow, repeatable request.

• Uses only approved data sources.

• Produces a draft or proposed action.

• Has its own visible identity.

• Cannot publish, send, merge, refund, purchase, or modify records without approval.

• Operates under a defined usage budget.

• Leaves enough history for a manager to reconstruct what happened.

This is more valuable than another general-purpose chatbot—and much safer than an invisible automation with broad access.

What Changed

1. GitHub put shared AI agent sessions inside Slack

Event: GitHub released a public preview of a new Copilot experience in Slack. A user can mention `@GitHub` in a direct message, channel, or thread to start an agent session.

According to GitHub, the agent can use the Slack conversation and permitted GitHub context to answer questions, triage bug reports, create or update issues, investigate failures, implement changes in a cloud sandbox, and open a pull request for review. The agent can continue working asynchronously after the original discussion ends.

The work is visible to the channel rather than hidden in one employee’s private AI session. Team members can inspect the plan, add context, redirect the agent, or stop it.

Verification status: Confirmed product release; public preview. The capabilities and availability are documented in GitHub’s official changelog. Performance and suitability for any particular company have not been independently established.

Why it matters: This is a meaningful shift in where automation starts. A casual team conversation can now become an executable assignment.

GitHub also provides several controls worth copying outside software development:

• Agent-created issues and pull requests are attributed to the Copilot app identity.

• Actions remain subject to existing GitHub permissions.

• Administrators must enable the cloud-agent policy.

• Usage can be managed through cloud-agent budgets.

• Repository administrators can require an additional human approval before agent-authored work is merged.

The operator lesson is broader than coding: when an agent participates in a shared workspace, it should not masquerade as an employee or inherit unlimited authority from whoever mentioned it.

Decision: ACT. Borrow the control pattern even if your business never uses GitHub Copilot: named agent identity, inherited least-privilege permissions, visible work history, spending limits, and approval before release.

2. GitHub brought a similar shared agent workflow to Microsoft Teams

Event: GitHub also released shared Copilot agent sessions in Microsoft Teams. Team members can mention `@GitHub` in a channel, thread, or direct message, then collaboratively plan and steer the work.

GitHub says anyone in the conversation can contribute context, while only participants with repository write access can trigger changes. The agent works in a cloud sandbox, and the organization can follow its progress in the Teams thread.

The Teams integration has two separate cost surfaces: agent sessions consume AI credits, while cloud-sandbox usage is billed separately. GitHub says both can be governed through organizational budgets.

Agent-created pull requests can also be subjected to an extra approval. If a repository normally requires two approvals, enabling this control raises the requirement to three for work created through the Teams integration.

Verification status: Confirmed product release; public preview. Features, permissions, billing behavior, and approval controls are described in GitHub’s official documentation. Real-world reliability will vary by task, repository, configuration, and reviewer quality.

Why it matters: The integration illustrates an important distinction between conversation access and action authority.

Everyone may be able to see or steer an agent session. That does not mean everyone should be able to authorize changes. GitHub uses the connected participant’s repository permissions to preserve that boundary.

Many SMB automations fail to make this distinction. A staff member who may discuss a refund, discount, vendor payment, hiring decision, or customer exception is not necessarily authorized to execute it.

The separate metering of AI credits and sandbox activity also shows why agent cost control needs to cover the whole workflow—not just model tokens. Browsers, execution environments, third-party tools, document processing, and repeated retries can all add expense.

Decision: ACT. Define separate permissions for requesting, steering, approving, and executing agent work. Track all variable costs associated with the workflow, not merely the AI subscription.

3. OpenAI and AWS emphasized structured requirements and checkpoints for long-running agent work

Event: OpenAI announced that its GPT-5.6 model family is available in Kiro, AWS’s software development agent.

The operationally important feature is not the model name. Kiro converts high-level intent into requirements, technical designs, and executable tasks. OpenAI says the agent can then work with repository context and team standards while allowing people to review and refine its output at key checkpoints.

OpenAI and AWS also report that GPT-5.6 Terra completed successful tasks on Terminal-Bench 2.1 in Kiro at roughly an 82% cost reduction. The announcement attributes that result partly to providing structured specifications and task context before execution.

Verification status: Confirmed availability; company benchmark claim. The integration and stated workflow are confirmed in OpenAI’s announcement. The cost-reduction figure was reported by OpenAI and AWS from benchmark testing; it should not be treated as a guaranteed reduction in a live business workflow.

Why it matters: Agent costs are often blamed on model pricing when the larger problem is vague work.

An agent given “handle this customer issue” may search too broadly, make assumptions, repeat tool calls, and produce an unusable response. An agent given an approved customer record, a defined policy, the requested outcome, a checklist, and a required output format has a better chance of completing the work efficiently.

That principle applies to nontechnical operations:

• “Follow up with this lead” is vague.

• “Using the approved service guide and the five fields in this lead record, draft a reply that answers the stated question, asks for the missing scheduling information, and makes no pricing commitment” is bounded.

Better models can improve results, but clearer task specifications can improve quality and cost across models.

Decision: ACT. Before changing models or buying more capacity, rewrite one agent task as a structured specification with permitted inputs, required outputs, forbidden actions, and review checkpoints.

4. Microsoft framed agent visibility and continuous governance as prerequisites for scale

Event: Microsoft published five signals it associates with trusted AI deployment: observability, security and privacy by design, continuous governance, operational accountability, and digital sovereignty.

Microsoft’s central observability questions are practical. For every agent, a business should know:

1. What agents exist?

2. Who uses them?

3. What systems and data can they access?

4. What outcomes do they produce?

Microsoft also argues that governance should be a continuous loop—“Map, Measure, Manage”—rather than a one-time approval before launch.

The article cites Microsoft’s own Cyber Pulse AI Security Report in claiming that 29% of employees use unsanctioned agents their security teams cannot see.

Verification status: Confirmed Microsoft guidance; company-reported research. The framework is published by Microsoft. The employee-usage statistic comes from Microsoft’s research and should be read as a directional company-reported finding, not assumed to describe every SMB.

Why it matters: Small businesses may not have an AI steering committee, security operations center, or dedicated compliance team. They still need an inventory.

Without one, an owner may know that the company pays for two approved AI tools while employees have connected several others to email, cloud storage, meeting transcripts, customer records, or source code.

The most dangerous agent may not be the most sophisticated one. It may simply be the one nobody remembers installing.

Continuous governance does not require a large bureaucracy. For a smaller company, it can be a monthly 30-minute review of:

• Active agents and integrations.

• Owners and authorized users.

• Connected systems.

• Recent actions and exceptions.

• Usage and cost.

• Data-retention settings.

• Failed or overridden outputs.

• Permissions that are no longer needed.

Decision: ACT. Create a one-page AI agent register before expanding agent access. If an agent has no named owner, permission list, activity history, or shutoff procedure, do not let it take actions.

The Business Problem This Creates

The immediate management problem is that work requests and execution are becoming compressed into the same interface.

Previously, a Teams message saying, “Can someone fix this?” was a request for a person to investigate. The employee would interpret the request, check authority, open the necessary systems, perform the work, and report back.

An embedded agent can remove several of those pauses. That is useful when the request is routine and well specified. It is risky when the conversation contains incomplete information, brainstorming, sarcasm, outdated instructions, sensitive data, or a commitment nobody intended to authorize.

Consider a familiar lead-handling workflow:

1. A new inquiry arrives.

2. A team member posts it in a shared channel.

3. Colleagues discuss fit, scheduling, pricing, and who should respond.

4. Someone asks the AI agent to “take care of it.”

5. The agent drafts—or possibly sends—a response.

What does “take care of it” mean?

• Summarize the inquiry?

• Enrich the lead record?

• Recommend a response?

• Quote a price?

• Offer an appointment?

• Update the CRM?

• Send the email?

• Start an automated follow-up sequence?

If those boundaries are not explicit, the agent and the operator may interpret the same instruction differently.

There are four management gaps to close:

Authority gap

The person who can request work may not be authorized to approve the outcome. Agents need separate rights for reading, drafting, proposing, and executing.

Context gap

A channel thread may not include the latest service policy, customer history, contractual restriction, or exception. Agents should work from approved sources, not treat every message as authoritative.

Accountability gap

If the resulting action appears under an employee’s account, it may be difficult to distinguish human work from agent work. A visible agent identity and activity record make review possible.

Cost gap

Asynchronous agents can continue using models and tools after the initial request. A short prompt can initiate a long and expensive process. Per-agent and per-workflow budgets are therefore operational controls, not merely accounting preferences.

Workflow to Test

Run a two-week inbound-inquiry draft assistant experiment. Keep it draft-only.

Input

Give the agent only:

• The inquiry text.

• The lead’s name, company, and approved contact details.

• The relevant service category.

• A current, approved FAQ or service guide.

• A short response policy listing claims and commitments the agent may not make.

Do not provide unrestricted mailbox, CRM, shared-drive, or accounting access for this test.

AI task

Ask the agent to produce:

1. A one-sentence summary of the inquiry.

2. A classification: qualified, needs more information, outside scope, or possible spam.

3. The evidence supporting that classification.

4. A proposed response using only approved service information.

5. A list of any missing information.

6. A clear warning if the inquiry requests pricing, legal terms, availability guarantees, refunds, regulated advice, or another restricted commitment.

The agent may draft. It may not send, schedule, quote, update the CRM, or start a follow-up sequence.

Human approval

Assign one role—not “the team”—to review every draft.

The reviewer should confirm:

• The classification is reasonable.

• The factual statements are supported by the approved guide.

• The agent did not invent availability, pricing, capabilities, or customer history.

• The response contains no unnecessary private information.

• The tone is appropriate.

• Any commitment falls within the reviewer’s authority.

The reviewer then sends the message manually.

Success measure

Track:

• Median time from inquiry receipt to approved draft.

• Percentage of drafts accepted without substantive factual correction.

• Number of unsupported claims.

• Number of missed restrictions.

• Percentage of inquiries routed to the correct next step.

• Total AI and tool cost per approved draft.

• Reviewer time per draft.

A useful result is not simply “faster.” The experiment should reduce handling time without increasing factual corrections, inappropriate commitments, privacy exposure, or lead-routing mistakes.

Stop condition

Pause the test immediately if:

• The agent exposes one customer’s information in another response.

• It sends or changes a record without approval.

• It repeatedly invents prices, availability, policies, or capabilities.

• More than 10% of drafts need substantive factual correction after the first calibration week.

• Cost per approved draft exceeds the value of the time saved.

• Reviewers begin approving drafts without reading them.

A stop condition is part of the workflow design, not an admission that the experiment failed.

Who should use it

This test is appropriate for businesses with:

• Repeated inbound inquiries.

• A documented service or product guide.

• A person responsible for inquiry review.

• A measurable current response process.

• Enough volume to evaluate the result over two weeks.

Who should not use it

Do not use this test for:

• Emergency response.

• Medical, legal, financial, or safety-critical advice.

• High-value contract negotiation.

• Complaints involving litigation or regulatory reporting.

• Refunds, payment changes, hiring decisions, or account access.

• Any workflow where nobody can reliably review the output.

What Must Stay Private or Human-Approved

An agent should receive the minimum data needed for its assigned task.

Keep the following private unless access is necessary, documented, and protected:

• Passwords, API keys, recovery codes, and authentication tokens.

• Full customer databases or unrestricted inboxes.

• Payment-card, banking, payroll, tax, and accounting records.

• Government identifiers and identity documents.

• Health, legal, disciplinary, and employment information.

• Private customer communications unrelated to the current task.

• Confidential contracts, negotiation notes, and internal forecasts.

• Proprietary files that the workflow does not require.

• Children’s data or other specially protected information.

Require human approval before an agent:

• Sends an external message.

• Publishes public content.

• Quotes or changes a price.

• Promises availability, delivery dates, performance, or outcomes.

• Issues a refund or credit.

• Purchases goods or services.

• Moves money.

• Deletes or materially changes a business record.

• Grants access or modifies permissions.

• Signs, accepts, or changes contractual terms.

• Makes hiring, firing, disciplinary, lending, insurance, or eligibility decisions.

• Merges software changes into a production system.

• Responds to a legal threat, safety incident, or regulatory request.

Human approval should mean reviewing the actual proposed action—not merely clicking a confirmation button beside an unread AI summary.

One Operator Decision

Implement a supervised, draft-only agent for one repetitive workflow—and do not expand its authority until it has a visible identity, least-privilege access, a usage budget, an activity history, a named human owner, and a tested stop procedure.

The current product direction is clear: agents will increasingly operate inside the tools your team already uses. The businesses that benefit will not be those that give agents the broadest access first. They will be those that define the cleanest boundary between conversation, recommendation, approval, and execution.

Repurposing Hooks

Podcast opening question: If an employee can mention an AI agent in a team conversation and start real work, who is responsible for checking whether that work was authorized?

YouTube hook: Before adding an AI agent to Slack or Teams, give it five things: its own identity, narrow permissions, an approval gate, a spending limit, and a stop button.

Quotable takeaways:

• “The right to discuss an action is not the same as the authority to execute it.”

• “A vague assignment can turn a cheap AI request into an expensive, unreliable agent run.”

• “If you cannot list an agent’s owner, permissions, costs, and recent actions, it is not under management.”

Source Index

• [GitHub] - https://github.blog/changelog/2026-08-21-the-new-github-copilot-experience-in-slack/ - August 21, 2026 - Confirmed public preview of shared Copilot agent sessions in Slack, including app identity, existing permission boundaries, budgets, sandbox execution, and optional additional approval.

• [GitHub] - https://github.blog/changelog/2026-08-21-shared-agentic-work-with-github-copilot-in-microsoft-teams/ - August 21, 2026 - Confirmed Teams agent sessions, write-access requirements, separate AI-credit and sandbox budgets, and additional approval for agent-created pull requests.

• [OpenAI] - https://openai.com/index/gpt-5-6-in-kiro - August 24, 2026 - Confirmed GPT-5.6 availability in Kiro; structured requirements, review checkpoints, and an OpenAI/AWS benchmark claim of roughly 82% lower cost for successful Terminal-Bench 2.1 tasks using GPT-5.6 Terra.

• [Microsoft] - https://www.microsoft.com/en-us/microsoft-cloud/blog/2026/08/24/5-signals-of-trusted-ai-how-organizations-scale-ai-with-security-governance-and-observability/ - August 24, 2026 - Microsoft’s guidance on agent observability, security and privacy by design, continuous governance, accountability, and sovereignty; includes company-reported shadow-agent usage findings.