Common services / A practical guide
An agent in Slack.
What does setup actually mean?
“Put an agent harness in Slack and it does everything.” It is an appealing claim. The useful question is: what context can it see, whose judgment does it follow, and what is it allowed to do?
The harness is the operating setup.
The assistant is only one part. Its harness is the surrounding system: access to information, instructions, tools, triggers, review gates, and a record of what happened. Slack can be where your team interacts with it. It does not have to be where every document or every system lives.
Start with one useful job. Build confidence in how it finds evidence and handles uncertainty before expanding its authority.
Phase 1 / Ask grounded questions
Connect the right context, not everything.
Connect an assistant such as ChatGPT, or a suitable provider, to the Slack channels and company information your organization permits. Agree on the audience, sources, retention, and access boundaries first. An employee’s access and an installed app’s access are not automatically the same.
For example: “What decisions did we make about the checkout launch, and what is still unresolved?” A useful answer links to its source threads, distinguishes decisions from suggestions, and says when evidence is missing.
OpenAI documents a ChatGPT Slack app, with availability and deployment controlled by workspace administrators. Slack apps use granted permissions to access data. The actual implementation must check the chosen app’s identity and access model; a custom integration must enforce authorization when retrieving and returning information. Do not assume connecting an assistant grants company-wide access.
Ready for the next phase: representative questions have source-backed answers, access checks pass, and someone owns the connection when permissions or team membership change.
Phase 2 / Give it a way of working
Make shared judgment explicit.
Write short, maintained Markdown playbooks: what the team is trying to achieve, the terms it uses, how to review a proposal, and when to escalate. Each playbook needs an owner, a version, and a review date. Keep sensitive documents behind the same access controls as their sources, and retire outdated guidance.
For a launch review, ask for distinct perspectives. A product reviewer examines customer value and success measures. An engineering reviewer examines reliability and implementation risk. A commercial reviewer examines pricing, positioning, and support readiness.
These are review lenses, not real colleagues being impersonated. Label generated perspectives as analysis; do not manufacture a person’s opinion or quote. Ask for evidence, assumptions, disagreements, and the decisions a human still needs to make.
Ready for the next phase: a small set of real proposals has been reviewed against a versioned checklist, the team has corrected recurring mistakes, and the output is useful enough to repeat.
Phase 3 / Run reviewed workflows
Move from answers to bounded actions.
Define a workflow explicitly: its trigger, permitted inputs, expected output, reviewer, allowed actions, and failure path. A question in Slack is not the same thing as a scheduled job. Alerts and actions need the appropriate app, workflow, scheduler, and real tool connections.
For example, a release-review workflow can gather authorized updates, apply the checklist, and prepare a risk summary for a named reviewer. An approved integration can then post an alert or create a ticket. Sending customer messages, changing permissions, spending money, or deploying software should remain behind an explicit approval gate.
Slack’s Events API can notify an installed app about selected activities within its granted access. That enables triggers; it does not itself supply the assistant, business logic, or permissions to take every follow-up action.
Track the source context and playbook version, who approved the action, the actual tool result, and the outcome. Add timeouts, bounded retries, duplicate-action protection, spending limits, and a stop switch. If a tool fails, report the failure instead of claiming success.
Ready to expand: the team can show which runs succeeded, which needed intervention, and how to stop or recover the workflow.
What we help you set up.
Decision Axis helps your organization choose a focused first workflow, connect permitted context, create and maintain playbooks, and introduce reviewed actions where your team already works. We shape the operating model as well as the integration: ownership, permissions, review, and measurement.
This is a setup and consulting service, not a published Decision Axis Slack app or a promise that an agent can do everything. The tools and capabilities depend on your providers, plans, workspace policies, and approved integrations.
Primary references
Integration details checked on 6 October 2026. OpenAI: Use ChatGPT in Slack; Slack: permission scopes; Slack: Events API. The staged setup and review approach above is our proposed operating model, not a claim that these providers implement it automatically.
Start with one workflow worth improving.
Tell us where your team works and what you want to make easier.
Talk about your setup ↗