What a future managed pilot is designed to include
The proposed model configures AlexAI for one community instead of shipping a generic
self-serve bot. Identity, memory, voice, access, usage, and admin expectations would be
reviewed before Alex is allowed to improvise in public.
One server. One Alex.
A separately configured AlexAI build, with memory paths and operating rules designed
for technical and operational separation that must be verified before launch.
Learn the room
Channels, tone, inside jokes, useful utilities, taboo zones, and hard boundaries are
mapped with the people who run the server.
Visible boundaries
Clear decisions around what can be remembered, where voice is allowed, and how
members know when AI features are active.
Human override
Owner/admin review for usage limits, dashboard access, feature access, public output,
generated media, and support expectations.
Built for communities with a pulse—and moderators
AlexAI fits adult Discord communities with active moderators, a recognizable culture, and a
reason to use a memory-backed teammate beyond novelty. Gaming clans, creator servers,
roleplay groups, private leagues, and long-running friend communities are the clearest
early fit.
Strong fit
- Adult gaming clan, creator community, roleplay group, private league, or
long-running friend server.
- Owner or admin team can approve memory, voice, and public-facing behavior.
- There is a real use case: events, creative media, lore, moderation support,
utility commands, recaps, or voice presence.
Not a fit yet
- Servers aimed at children or teen safety-sensitive audiences.
- Communities that need instant install, self-serve billing, or enterprise SLAs.
- Spaces where members cannot be told when memory or voice features are active.
The proposed setup path
If pilots open, setup would be hands-on because memory, voice, and server identity deserve
more care than an invite URL and a cheerful checkbox. Every consequential choice would have
an owner.
1. Server map
Purpose, member count, active channels, moderation style, age posture,
and where Alex should show up first.
2. Feature scope
Pick the first useful bundle: chat, memory, utility commands, recaps,
generated media, voice, or admin pages.
3. Voice and memory
Decide what is on, off, opt-in, excluded, deletable, retained, and
visible to members.
4. Personality pass
Build a server-specific Alex prompt that fits the community without
cloning eR33t's private jokes onto someone else's couch.
5. Quiet launch
Start in selected channels or a test space, review behavior, tune
limits, then widen only when the server is ready.
How future pilot terms would work
There is no current pilot offer or public price. If the program opens, any invitation would
be scoped case by case, with operating boundaries, expected support, and cost posture agreed
before launch.
Managed setup
Configuration, operation, updates, and support are defined by the agreed pilot scope.
Measured usage
Model, media, voice, storage, and hosting use are visible and addressed in the pilot
terms instead of becoming a surprise later.
Plain-language terms
Any fees, discounts, support expectations, and budget boundaries are documented before
Alex joins the server.
A clean exit
Access, retained data, and end-of-pilot handling belong in the written scope, not in
an awkward conversation after the fact.
No pricing theater: the server owner sees the scope, boundaries, and cost posture before
Alex gets access.
Boundaries before personality
A future AlexAI pilot would not be installed as a silent observer. Memory, voice, public
output, and admin access must be decided and made visible before launch.
Memory
What gets remembered, what gets excluded, who can ask for deletion, and how long
pilot records are retained.
Voice
When AlexAI may join voice, whether voice memory is enabled, and how members know a
bot is present.
Public-facing pages
Whether logs, generated media, blog-like content, or status receipts can be made
public, and what is redacted first.
Admin access
Who can view admin pages, adjust bot behavior, inspect memory, or request
operational changes.
What happens after you register interest
Interest is recorded, but pilot review is not open. Readiness gates come first. If the
program later opens, we may contact a small number of communities for fit review. Compute
is fast. Trust remains stubbornly sequential.
1. Interest recorded
Submit community context and boundaries. This does not reserve a
place or start onboarding.
2. Readiness gates
Isolation, backup, privacy, security, and operator support must pass
before external invitations are considered.
3. Program decision
If the program opens, selected communities may be contacted for a
separate fit review. Interest alone creates no entitlement.
4. Pilot review
We evaluate usefulness, friction, safety events, and what must change
before broader rollout.
Register interest—not an application
Use the interest form and include community size, your role, likely use cases, the
features you want first, and any safety, privacy, voice, moderation, or budget boundaries.
Specific constraints beat a paragraph of enthusiasm every time.
No pilot is currently available. Interest is nonbinding and may not
receive a response. Any future invitation would require a separate written agreement.