How We Manage AI Agent Approvals in Slack With an Obsidian Vault

An approval needs a decision and a record

We use Slack to surface work for people and an Obsidian vault to retain durable context. Scheduled routines connect parts of that workflow. The useful pattern is to separate a notification from permission to act, and to preserve the decision somewhere a later session can find it.

This is an architecture guide based on our operating approach and current released plugin contracts. It is not a live inventory of every channel, routine or deployed handler. For a production action, check the current configuration and result; a description in an article is not authority to merge, send or change a record.

If your team works across agent chats, tickets and scheduled jobs, start with one bounded handoff. The design below explains where the proposal appears, who decides, what the executor must check and how the result becomes reusable context.

Part 1: Slack, the control room

Three layers of channels

Separating channels by audience and purpose helps people find the decisions they own. Our pattern distinguishes client work, shared operations and agent handoffs.

Client channels keep a project’s pull requests, deployments, error reports and intake notifications together. Include links to the authoritative records so a reader can inspect the current state without assuming the notification is still fresh.

Shared operations channels carry cross-project signals such as monitoring summaries, tooling changes and internal reports. Name the owner and the expected response when a post needs action; otherwise label it as informational.

Agent handoff channels carry proposals and task packages for a defined audience. Limit access to people who need the material, and avoid exposing customer information simply because a channel is convenient.

The baseline is notify-only

A notification should usually be a concise summary and a link. Reading the card must not silently authorize the next action. AI-written changes need the same relevant review and deployment checks as other changes.

Distinguish vendor-supplied actions from your own buttons. A button that resolves an issue, changes an assignment or sends a report has an external effect, even if it looks like a notification. Check that integration’s permissions and current behavior before enabling it.

Route interactive requests through a checked handler

Slack sends interaction payloads to the application’s configured request endpoint. A routing layer can dispatch different action identifiers to the relevant workflow. Central routing is useful for shared checks, but it is not a substitute for action-specific authorization.

For a custom handler, verify the request signature and timestamp according to Slack’s documentation, then check the actor’s permission for the specific action. Before merging, re-read the exact pull request head and all required checks and approvals. A single green check is not a sufficient merge policy. Bind the approval to the reviewed revision and prevent duplicate execution.

Design the refusal path before the success path. If the handler cannot read a required check, the target changed after approval or the requester lacks authority, hold the action and explain the missing condition. Do not turn a permissions error into permission to proceed.

The interactivity ladder

The table is a design ladder, not a claim that every integration currently implements each capability. Most notifications can stay at the first level. Add an action only when there is a clear owner, a recurring decision and a reliable verification path.

Three workflow patterns to adapt

Issue triage. Separate collection, investigation and remediation. An alert can lead to a read-only investigation and a proposed fix, with links to the issue, change and validation. Resolving the issue or merging the fix is a distinct action. Preserve a reason for a hold and make sure repeated alerts do not create duplicate work.

SEO monitoring. A routine can collect search-console findings and crawl or certificate checks, then report what was observed. Name unavailable sources instead of presenting an incomplete scan as a clean bill of health. A report should distinguish a current failure from a historic warning.

SEO remediation. Put confirmed issues into a scoped queue. Prepare the smallest relevant change, run its checks and expose the preview and source record for review. Recheck the approved revision and the applicable merge policy before execution; opening a pull request is not the same as fixing the live site.

Indexing follow-up needs its own boundaries. A submitted sitemap or URL is not proof that a search engine indexed it. Use the supported mechanism for the content and search engine involved; do not assume a general indexing API is available for every ordinary page. Verify the resulting public and search state separately.

Client report delivery. Build and store a reviewable report, identify its recipient and exact content, and request approval for that version. A later edit should require a new decision. Record provider acceptance separately from inbox delivery. “Request changes” should capture actionable feedback without sending the report by accident.

Part 2: The vault, where everything we learn goes

Use Slack for the conversation and a durable record for the conclusion. Our vault is a set of Markdown files that people can read in Obsidian and permitted agents can access through configured tools. Keep canonical decisions, evidence and open questions there, with links back to the task or source.

How it is organized

Areas holds continuing knowledge by domain. Projects holds active work and project-specific decisions. Daily Logs provides dated observations. Inbox is a temporary capture area that needs an owner and a processing routine. These are organizational choices, not a requirement to copy our folder names or achieve a particular note count.

What the agents write there

A useful report records its scope, source coverage, findings, action taken and unresolved conditions. A project handoff records the current goal, verified facts, decisions and next safe step. Content projects can retain the approved brief, research, article and derivative drafts together. Store only what the next reader needs, with appropriate access and retention.

How it flows back into the agents

The vault feeds decisions through four layers, and it helps to be precise about which layer does what.

There are several distinct mechanisms. Instructions can point to canonical notes; retrieval can bring relevant context into a task; project state files can carry a handoff; and a procedural registry can hold reusable methods. Configure and verify each mechanism on the host that will use it. A file existing in the vault does not prove a new agent session loaded it.

Treat a learned recipe as a candidate until reviewed. The procedural-memory registry distinguishes promotion, verification and execution health. Scheduled discovery can propose an improvement, but that does not automatically grant permission to change instructions or execute the proposal.

The example that wrote itself

When code, a comment and an old plan disagree, inspect the current configuration and observable behavior. Record the exact source, date and outcome that resolves the discrepancy, then update the relevant note. This avoids teaching the next session an obsolete operational claim. A failed check or unavailable source belongs in the record as well.

Part 3: Give each scheduled routine a narrow contract

For each routine, identify its inputs, allowed outputs, external effects and failure behavior. A report-only routine and a routine that can modify records need different controls. Scheduling a job does not expand its authority.

Store cadence in the active scheduler and keep the documentation linked to that configuration. When migrating schedulers, verify the old job is disabled, the new job is enabled and the delivery path works. Avoid claiming a migration is complete from a file edit alone. An unavailable input should remain visible in the report.

Use three broad categories: report, queue and mutate. Report routines collect and summarize. Queue routines prepare candidates for review. Mutation routines need explicit scope and checks for the effects they can cause. For example, an unavailable evaluator must produce a hold, not a successful result from a mock fallback.

A useful run receipt records identity, time, input coverage and outcome. Include token or cost data only when the provider supplies a trustworthy measurement; an unknown cost is not zero. An unrun baseline cannot support a savings claim. Preserve the last known good artifact when a refresh fails, and label it as stale.

Handing work to a person

The current delegate-to-teammate skill resolves a configured recipient and creates a concise Jira task, with an optional Confluence implementation brief for detailed work. It posts the handoff to the configured Slack channel and thread; approved supporting documents can become Slack Canvases. Stable delegation identifiers support recovery after partial failures. Configure destinations and review the task before external creation.

What this buys a small team

A clearer place to look. Slack can show the current request, while the task record and vault retain the durable detail. Each summary should link to its authoritative record rather than create a competing version.

Decisions with evidence. Record what was approved, by whom, for which revision and what actually happened. A declined check is a useful result when it prevents an action with missing evidence.

Reusable knowledge. A resolved mistake can become a reviewed instruction or procedure. Keep provenance and tests with the method so the next session can decide whether it still applies.

The operating principles are simple: begin with notifications, add actions deliberately, make authority specific, preserve failures and write durable conclusions. Centralize shared checks where that helps, while keeping each action’s own validation. No tool or channel arrangement removes the need to inspect real outcomes.

FAQ

Do you need n8n, or is Slack enough? Slack can present notifications and collect interactions. An action needs a handler that implements the relevant authorization and execution checks. n8n is one option; a hosted service or application endpoint can also work. Choose based on your existing stack, reliability needs and total maintenance cost.

Why use Obsidian instead of a wiki or database? Markdown files are portable and can work with familiar editors and version-control tools. A wiki or database may fit collaboration and access control better. Choose the system your team can maintain; the important contract is a findable, current record with appropriate permissions.

How do you keep a scheduled agent from making things worse? Limit its access, define its allowed outputs, verify its results and review holds. Report-only work has fewer operational effects, but can still expose sensitive data or mislead readers. Treat quality and access controls as part of every routine.

Implementation references: https://docs.slack.dev/interactivity/handling-user-interaction/ ; https://docs.slack.dev/authentication/verifying-requests-from-slack/ ; https://github.com/Rhize-Media/rhize-plugins/tree/main/rhize-ops . Validate the deployed handler separately from these design recommendations.

If you want to design an approval and knowledge workflow for your team, book a 30-minute call with Rhize at /book. Bring one recurring handoff and the systems involved so the discussion can focus on a useful next step.