An open source Discord agent that asks before it acts

An approval covers one action, once, with an end

A thread in a Discord server can ask an agent for real work. Refund the duplicate charge. Merge the fix. Close the three stale tickets. Each request ends in a call to a system that does not undo easily. Once the agent has done the thinking, the question is who says yes, and to what exactly.

Kortix treats that as an approval rather than a permission level. The connector rules give every action one of three settings, and a held action is a single call with its arguments attached. The Guide is worth reading closely here: "An approval covers one exact action. A changed detail needs a new approval." An agent that prepares a refund of 40.00 and then corrects it to 400.00 has not been approved for the second amount.

Two more properties keep the decision small. "An approval runs the action once. The agent does not send it again." And "A held action expires when nobody decides within 24 hours, unless your project sets another time." Silence is not consent; it is an expiry, and the call does not run.

There is no blanket yes either. The Guide states that there is no "approve everything for this session", so a call that must run unattended needs an Allow rule instead. That is the trade in one line: a standing rule for the routine call, a person for the call that matters.

The decision stays with the session

When the agent needs a decision on a Discord request, the held call stays with the session the thread started. It opens under Approvals in the session header, on Review → Needs you, or through the approval link, and it shows what the app will receive, with private values hidden.

The deciding set is narrow on purpose: a project manager, or the person who started the session. That is a shorter list than a support queue, and it is the right one for an action that came out of a conversation.

In a Slack or Teams thread the Guide goes further and puts an approval card in the thread itself: title, summary, a risk note, Approve and Deny, and View in Kortix on every card. A Discord thread has no such card in the Guide. What it keeps is the attachment, because the request never leaves the session the thread began.

That attachment is what a separate queue loses. The person who knows whether the refund is right is often the one who asked for it, and the session already holds the thread, the plan and the arguments. Keeping the decision on the action means the context travels with the yes.

Allow, Ask, Block: the rules you set decide

Every tool follows one of three rules. Allow runs the action at once. Ask holds it until a person approves or rejects it. Block never runs it. A connector can also be marked sensitive, which puts every action without its own rule behind an approval, reads included. A project can take a careful default instead: reads run, and writes or deletions wait.

"Approval gates you set. Off until you set them." A new project does not ask before a write. The gate exists once someone configures it, per agent and per connector, and the setting sits in the project's files where the next person can read it.

The second gate is a change request

Approvals cover calls to other systems. Changes to the project itself take a different route. An agent that edits a skill, its memory or another agent opens a change request, and a person reviews it on the Review page and selects Ship it.

"Session work reaches main through a change request. Merge is default-deny for agents." An admin can grant the merge capability, and the built-in agent's standing instructions tell it to stop after it opens one, so a person merges in normal use. To require a person every time, remove the merge permission from that agent. Default-deny is the setting; the grant is the deliberate exception.

What the record keeps

"Every action is recorded. Reading, exporting and streaming the audit log depend on the plan." Recording is not gated; access to the log is. The pricing page lists advanced RBAC and audit logs on Enterprise, so check the plan before a review depends on reading the log yourself.

The record is what makes the small gate worth having. A connector records every call it makes, and every action is recorded. Three weeks later, when someone asks why a refund went out, the held call, the decision and the result are still in the session. No one has to remember.

The other options put the decision elsewhere

OoriData's Discord-AI-Agent is a readable bot for chat over MCP servers, and its README covers installing and configuring it, not an approval layer. AgentX deploys an agent built in its builder and ends the walkthrough at /ask in a channel. Beam.ai routes an exception to the person responsible for the outcome inside a Beam workflow. Mava is a support inbox where a person takes over a conversation from the AI reply.

Beam and Mava put a person in the loop, at the workflow exception and at the support reply. Neither attaches the yes to the specific tool call that a Discord thread asked for, which is the unit an agent that refunds, merges or closes actually needs. OoriData and AgentX leave the question to whoever runs the bot.