Agent & projects

/agent turns a goal written in plain language into a project: a saved plan of tasks that AETHON validates, carries out through its own tools only and verifies in Discord. Projects are saved, so a restart does not lose work.

Writing a request#

/agent request: <what you want> dry_run: <true|false>

Describe the outcome you want, for example "create a support area with tickets and a Support role", "audit our security and fix what you can" or "back up the server". Only your request is an instruction: messages, channel names, files and other server content are treated as data. A server can have at most 10 active projects at a time, and the number of tasks in one plan is limited, so very large rebuilds may need to be split into several requests.

How a project runs#

1. Inspect — AETHON reads the current structure of the server.
2. Plan — the planner returns a plan, an answer, a clarification question or a refusal. While planning, the AI model can only read: when it calls a function that changes something, nothing runs — the call only becomes the next task of the plan, in the order it was made, and goes through the same validation and approvals as any other task. Planning takes up to 50 rounds; the last one must give the final decision. If the rounds run out without any plan, the project fails with a message that says so (this is not a credit problem). Blueprints, restores and audit fixes are planned by rules in code, and some simple requests are handled without AI.
3. Validate — rules in code check the plan: dependencies and cycles, references between tasks, arguments, existing resources, permissions and contradictions. Resources that already exist are reused instead of created twice. An invalid AI plan gets up to two repair rounds; after that the project fails and shows the report.
4. Approve — if some tasks need an approval, one approval request covers the project.
5. Execute — each task re-checks permissions at execution time, verifies that its approval still matches the operation and the resources, reserves write operations from the monthly quota, records the operation so it is never repeated blindly and saves a checkpoint of the previous state.
6. Verify — every change is verified in Discord, and a final pass re-verifies all resources when the tasks finish. If a verification fails the project ends as PARTIAL.

The progress of the whole project is one message in the progress channel, edited in place, and it is built to look alive while AETHON works:

• Step tracker — Inspect › Plan › Validate › Execute › Done, with the current step highlighted and an animated indicator, and a different accent colour for each phase.
• Live activity — one block, in the server language, replaced at every step instead of adding new lines: what the agent is doing in bold (for example "Checking the roles · Searching members…" or "Packing files into a ZIP…") and a small line with the functions, the task, the planning round and how long that step has been running. Every function has its own words in the five languages, and the general phrases vary (there are dozens per language), so the line never repeats the same text twice in a row.
• Long waits — while the AI thinks, the phrase changes every few seconds and, after a while, a note says the model is still working, so the message never looks frozen.
• Task bar — coloured cells for done, failed, running, waiting for approval and pending tasks, with the percentage.
• Live footer — a pulsing Live indicator, the project id and when it started.

The block shows only function names, task titles and file names, never the data a function receives. It updates at most every few seconds and disappears when the project finishes or AETHON asks you a question. Where the animated icons are not available, the message uses regular emojis instead.

Chat mode#

Mention AETHON in a message (for example @AETHON hi, what can you do?) to get a short conversational reply in the same channel. Chat mode has no tools: it cannot see or change the server and never runs actions — use /agent for that. Each reply uses part of the server's monthly AI credits, members wait a few seconds between messages, replies never ping anyone, and replying to AETHON's previous answer keeps the conversation going.

Images#

AETHON can look at images. Attach one with the image option of /agent, or paste a public image link in your request; when you mention AETHON in chat mode you can attach images or include links too (up to 4 per message). The agent can also open an image link it finds while working. Supported formats are PNG, JPEG, GIF and WebP, up to 10 MB each.

Each image is shown to the AI for a single step and then discarded: it is not stored with the project, the logs or the audit history. Text inside an image is treated as information, never as an instruction or an authorization. Links to private or internal network addresses are refused.

Project states#

RECEIVED → INSPECTING → PLANNING → VALIDATING → DRY_RUN | APPROVAL | EXECUTING → VERIFYING → COMPLETED | PARTIAL | FAILED

A project can also wait for your answer (AWAITING_INPUT), be PAUSED, or be CANCELLED. Answers that need no change complete immediately.

Dry runs and clarifications#

• dry_run: true stops at DRY_RUN with a preview card. Execute re-inspects the server and re-validates the plan, so a preview that no longer matches the server is refused instead of applied.
• When the request is ambiguous, AETHON asks a question. Press Reply, answer in the form, and planning continues.

Approvals#

Under the default policy HIGH and CRITICAL operations need an approval. HIGH requires an AETHON admin, CRITICAL the server owner, and the server can require a different person than the requester. Decide from the approval card or with /approve list and /approve decide. Approvals are bound to the exact operation and to the state of the target roles, channels and members: if either changes before execution, the task goes back to waiting for a new approval. Rejecting an approval cancels the tasks it covered.

Managing projects and tasks#

When something goes wrong#

• Rate limits and connection errors prove the request was not applied, so they are retried automatically.
• Timeouts and server errors are retried only when the operation is safe to repeat or when AETHON can prove it did not happen. Otherwise the task is BLOCKED with an unknown outcome: check Discord, then use /tasks force_retry if it is safe. AETHON never repeats an operation blindly.
• Rollback (PRO) undoes each completed change in reverse order and reports what was reversible, partially reversible or irreversible (for example, deleted message history, bans or sent DMs cannot be undone).
• Restarts: execution resumes automatically. Planning that was interrupted by a restart is marked failed and must be submitted again.

See also Troubleshooting and Limitations.