An open source Discord AI agent you can read before it acts

What open source changes when the bot can act

A Discord bot that answers questions is easy to hand to a vendor. One that reads your tickets, your repository, and your deploy logs is a different decision. It reaches into those systems with credentials you granted it. The code that decides which call it may make is the part you need to read. So the question is narrower than a license: can you read that code, change it, and run it yourself?

Kortix is a git repo, and a project is a git repo. kortix.yaml declares the project: it lists the agents and the skills, tools, connectors and triggers they use. Before anyone mentions the bot in a channel, you can open the file and see what the agent is allowed to reach. The manifest sits in a repository you can clone. Open source. Read it, fork it, audit it. A rule change is a diff somebody reviews.

The rule that decides what the agent may touch

Each agent block can carry a permission map: one action for a whole tool, or a pattern that matches a command or a path. The action is allow, ask or deny. In the reference's example, git push waits for a person, rm -rf never runs, and edits under secrets/ are denied.

That map is the part a closed builder does not show you. You can point at the line that stops a delete and at the line that holds a push. When a rule is wrong, you change it in the repo. Approval gates you set. Off until you set them. When an agent asks, the request stays with the session the thread started. Open that session or the Review page in Kortix and choose Approve or Deny on what the app will receive. The approval covers one exact action and expires after 24 hours unless the project sets another time.

Check what the file leaves out

The reference is blunt about what an empty block does. Three keys are open by default: tools is all (kortix validate warns when an agent omits it), permission is allow, and codemode is on. An omitted permission is allow, so a manifest that declares nothing about permissions runs every tool call without asking. That is the trap in a copy-pasted config: the file is readable, and it is permissive.

Read the omissions before you trust the rules. Set the calls that touch production to ask, set the ones that must never run to deny, and check the diff when the file changes. A fork you never read is no safer than a hosted builder you cannot read.

What the bot can see in a server

In a server, only a mention reaches the agent. One thread is one session, so the question and the work that follows it stay together, and the reply lands where it was asked. Without the Message Content intent the agent cannot read other people's messages. It sees mentions, direct messages and its own messages. The app asks for the permissions it needs when you add it, and one project makes at most 60 Discord calls a minute.

Where the readable code stops

Self-hosting is the clearest form of that control, and it has an edge worth naming. The kortix CLI installs the web app, the API, the LLM gateway and the database on your server as one Docker Compose stack. It keeps that stack up to date. Sessions and Drive run on Platinum sandboxes that call back to your instance. So the app and the rules live where you put them, while the agent's computer is a remote sandbox that has to be able to reach you. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free.

Connector credentials are brokered server-side and never enter the machine. A call to your CRM runs with a login the sandbox never holds, so the credential stays on the server side of the call.

The other open source Discord bot

OoriData's Discord-AI-Agent is the open source bot most teams find first. It is a Python bot for AI chat over the Model Context Protocol, installed with uv pip install -U ., configured by copying config/example.main.toml to config/main.toml, and pointed at an OpenAI-compatible endpoint, OpenAI or Anthropic. It is small and open: one maintainer, last commit 2025-10-31, no license file in the repo.

You can read all of it, which is the point. What you take on is its shape: one maintainer's config file, a chat surface, and the pace of a single-maintainer project. For a personal assistant in a hobby server that is a good trade. For an agent that can reach a production system, the rule that decides what it may touch should sit in a file your company reviews, next to the connectors it grants. Kortix puts that file in the same repository as the agents and the skills. The answer to what an agent can reach is a path in the repo, and you can open it. Add the app, read the manifest, set the rules, then mention it in a thread.