The short version
You describe the outcome in normal language. ARVN reads the server context it is authorized to use, creates a structured plan, explains the proposed result and waits for confirmation. Eligible changes then pass through permission, freshness, package-integrity and execution checks. ARVN does not bypass Discord permissions and it does not turn ordinary conversation into an unreviewed mutation.
The operating model
How the workflow works
The chat is the interface, but a deterministic execution pipeline remains the authority for real changes.
- 1DescribeAsk for the outcome you want in everyday language, including important constraints.
- 2GroundARVN uses the connected server context and registered capabilities instead of inventing Discord resources.
- 3PlanThe request becomes structured operations with targets, dependencies, risk and expected state.
- 4ReviewARVN explains what will change and what will remain untouched.
- 5ConfirmYou approve the current, bound version through the conversation. Material plan changes require a new review.
- 6Execute and verifyWhere live execution is enabled, the executor re-checks state and permissions, applies the operation and reads the result back.
Task families
What ARVN can help with
ARVN is built around typed operations rather than unrestricted bot commands. Exact availability is evaluated for the current server and request.
Server structure
Plan and, where enabled, create, update or remove channels, categories, roles, threads, webhooks and supported AutoMod rules.
Permissions
Plan role permissions and role-based channel or category overwrites with privilege and reference checks.
Server settings
Prepare supported server-setting changes that remain bound to the connected guild and fresh server state.
Members and moderation
Prepare supported member-role, moderation and voice-state operations with explicit targets and risk handling.
Messages and events
Handle supported message, invite and scheduled-event workflows through closed operation contracts.
Modules and analysis
Explain module capabilities, generate configuration drafts, preview changes and audit parts of the server setup.
For module-specific detail, browse the module documentation. For the broader product view, see ARVN AI.
Conversation example
From request to verified outcome
A useful request names the outcome and the boundaries. You do not need to translate it into API fields.
This is an illustrative workflow, not a promise that every listed combination is enabled for every account, plan or server.
Human control
What confirmation protects
Confirmation is authorization for one exact proposal—not general permission to keep changing the server.
- Server, user and conversation identity
- Plan and plan-revision identity
- Confirmation challenge and expiry
- Canonical plan and package hashes
- Current server-state revision
- Required user and bot permissions
- Operation risk and second confirmation where required
- Credit reservation before execution
A changed plan must be reviewed again
If the plan, revision, challenge or relevant server state no longer matches, the request fails closed. A previous “yes” cannot approve a materially different package.
After mutation
Verification, retries and recovery
An API success response is not treated as proof that the intended server state exists.
- Fresh read before mutation
- Minimal operation-specific change
- Durable pre-mutation intent
- Post-mutation server re-read
- Canonical result per operation
- Idempotent replay after worker retry
- Partial completion reported honestly
- Reconciliation instead of guessed settlement
Verification support depends on the operation. When the executor cannot prove the result, it must report that honestly rather than labeling it verified. Execution history keeps the operation-level outcome, warnings and verification facts available for review.
Honest boundaries
Availability and current limits
Built capability, account access and live execution are separate questions.
Availability can vary
Features can depend on the server, account, plan, connected bot permissions, capability registration, rollout gates and the live execution allowlist. The interface shown for your current server is authoritative.
Discord remains authoritative
ARVN cannot exceed the bot’s Discord permissions, bypass role hierarchy, invent trusted resource IDs or guarantee a change Discord rejects.
Not every Discord feature is equivalent
Some operations are fully executable and verifiable, some are preview-only, and unsupported or ambiguous fields remain blocked until they have a closed contract and reliable verification.
Never use an AI-generated plan as a substitute for reviewing administrator access, legal obligations, moderation policy or irreversible community consequences.
Fault isolation
Troubleshooting ARVN AI
ARVN fails closed at several boundaries. The visible message identifies where to investigate; retrying repeatedly without resolving that boundary is rarely useful.
| What you see | What it usually means | What to do safely |
|---|---|---|
| ARVN could not answer / provider unavailable | Provider refusal, timeout, rate limit, invalid structured response or temporary health circuit | Retry once after a short wait. If it repeats, keep the message and timestamp, verify provider status and do not manually reconstruct a mutation from a partial response. |
| No plan or confirmation appears | The request was informational, ambiguous, unsupported, capability selection failed or the plan produced no valid operations | State one outcome and explicit constraints. Name existing resources exactly. Resolve open questions; do not treat ordinary assistant prose as an executable plan. |
| Plan or server changed / STALE | Plan revision, challenge, capability artifacts or server-state revision no longer matches | Refresh the conversation state, review the newly generated plan and confirm that version. Do not try to reuse the earlier confirmation phrase. |
| Missing permission evidence | User authorization, bot membership, application identity or required Discord permissions could not be proven freshly | Reconnect the correct Discord account, recheck bot installation and hierarchy, then generate a fresh confirmation. Never fabricate permission arrays or IDs. |
| Not in execution allowlist / feature disabled | A rollout or kill-switch gate intentionally blocks live mutation | The plan may remain useful as a preview, but it is not executable. Only an authorized operator should change rollout configuration after preflight. |
| Budget reservation missing or expired | The bound reservation is absent, no longer active or no longer matches the package | Generate a fresh plan/confirmation path. Do not create ledger rows or reservations manually to force execution. |
| Drift detected before mutation | A relevant Discord resource changed after review | Inspect the live server change, regenerate the plan against current state and re-confirm. Drift blocking is expected protection, not a retryable adapter error. |
| Partially completed / reconciliation required | Some operations may have real effects while a later operation failed or settlement cannot be inferred safely | Stop retries. Inspect execution details and Discord state, preserve audit evidence and use the authorized reconciliation workflow. Do not guess a partial credit settlement. |
| Execution finished but not VERIFIED | The adapter could not prove the intended post-mutation state, or the operation’s verification method is unavailable | Read operation facts and warnings, inspect Discord directly and avoid claiming success until the target state is independently confirmed. |
| Response vanished after reload | A turn failed before a durable assistant response, or persisted failure/reconstruction data is incomplete | Use the bound retry action on the exact user message. Do not submit a second differently worded mutation until you know whether the first created a plan or execution. |
Operator reference
A disciplined diagnostic sequence
Use evidence from the narrowest layer first. A green UI message alone is not enough to override a failed server-side boundary.
- 1ConversationIdentify the exact session, user message and visible failure. Preserve the wording and timestamp.
- 2PlanConfirm that a persisted plan exists, its revision is current and all proposed operations are valid and supported.
- 3Capability artifactsCheck that successful results are persisted and bound to the finalized plan identity.
- 4ConfirmationVerify the challenge is pending, unexpired and belongs to the same user, session, plan revision and server state.
- 5PermissionsRe-read authoritative user and bot evidence; inspect Discord role hierarchy and target-specific access.
- 6PackageValidate canonicalPlanHash, packageHash, dependencies, risk, allowlist and reservation binding before adapter work.
- 7ExecutionUse executionId to inspect operation steps, durable intent, result facts, verification and reconciliation state.
Information worth attaching to a bug report
Timestamp, server and session identifiers, executionId when present, exact safe error code, plan revision, browser action that preceded the issue and whether Discord shows a real effect. Never attach API keys, bot tokens, confirmation challenges, raw prompts or unrestricted database dumps.
Better requests
How to get better results
Specific outcomes and explicit constraints produce safer plans and fewer clarification rounds.
- Name the intended outcome
- State what must not change
- Use exact existing resource names when editing
- Separate unrelated projects into different turns
- Answer clarification questions before confirming
- Review permission grants carefully
- Use a fresh plan after manual Discord changes
- Check the execution result and verification status
When designing a full server, begin with the Discord server foundation guide, then ask ARVN to translate the approved blueprint into staged, reviewable operations.
FAQ
Questions and answers
The most important distinctions before using conversational server management.
Does ARVN change my server just because I ask a question?
No. Informational conversation is separate from a confirmed execution package. A real mutation requires the applicable planning, confirmation and execution boundaries.
Can ARVN bypass Discord permissions?
No. Discord permissions, role hierarchy and resource ownership remain authoritative. Missing or stale evidence blocks execution.
Can I confirm by replying naturally?
Supported confirmation phrases can be recognized deterministically when the latest conversation context is the live confirmation question. Ambiguous or interleaved replies do not silently authorize a change.
What happens if the server changes after the plan?
Relevant state drift invalidates the stale execution path. ARVN asks for a fresh review instead of applying assumptions from the older snapshot.
Can ARVN build an entire server?
The architecture supports multi-resource plans and dependency ordering, but rollout limits and supported operation shapes still apply. Large builds should be reviewed and executed in deliberate stages.
Where can I see the result?
The execution status surface reconstructs persisted operation results, verification state, warnings and errors rather than relying only on temporary chat state.
Start with a server you control.
Use a test server, request one clearly bounded outcome, review the plan and confirm only when it matches your intent.
Create an account