SLAIBot · AI staff that live and work inside Second Life

More than a chatbot wearing an avatar.

SLAIBot turns a real Second Life avatar into an AI employee. Depending on the job you give it, a bot can talk with residents, remember people, answer questions, move around, face people, dance, DJ, host events, greet guests, give directions, help with rentals and sales, interview job applicants, scout advertising locations, coordinate with other bots and hand difficult situations to a human.

The important idea is simple: each bot has a job. A DJ should behave like a DJ. A greeter should behave like a greeter. A hiring manager should interview people privately. An advertising scout should go out and find places to advertise. The same platform powers them, but each bot only gets the abilities appropriate to its role.

What a full SLAIBot can do

Talk naturally

Bots can hold normal conversations in local chat and private IM. They can answer follow-up questions, keep track of what the person is talking about and avoid sounding like a vending machine full of canned replies.

Remember people

A bot can remember useful facts, preferences and prior interactions so the next conversation has continuity. Memory can be kept separate from private owner information, and memory can also be removed when appropriate.

Know where it is

The bot reports its real Second Life region and position instead of guessing. It can also use shared property and venue knowledge so it understands the difference between places such as Phat Cats, The Bricks and PhatLand.

Know who is nearby

Bots can see nearby avatar presence through Second Life data, recognize arrivals and use that information for greetings, hosting and crowd-aware behavior.

Move safely

Depending on the job, a bot can walk to a person or destination, roam within a defined area, follow routes, visit tour stops and approach guests while staying inside its assigned boundaries.

Stay exactly where it belongs

Stationary staff can be tied to position-anchor objects. If a worker is restarted, the system is designed to capture its real position first and restore the avatar to the same place rather than sending it to a guessed home location.

Face the person or crowd

A host does not have to stare at a wall. Bots can turn toward guests, a stage audience or an assigned direction without necessarily walking away from their post.

Dance

Bots can use their own animations or shared male/female dance-ball systems. Dances can be selected by tempo, and movement-producing dances can be blocked for staff who must remain planted in one spot.

Change outfits

A bot can scan its Second Life outfit folders and wear a requested outfit when that capability is enabled.

Read public profiles

When permitted for the role, a bot can fetch public Second Life profile information to better identify or assist a resident. Private information is not invented or treated as public profile data.

Use live web information

Some roles can use current public web information when a question calls for it, rather than being limited to whatever was known when the bot software was created.

Escalate to a human

When the bot does not know something, lacks permission, or encounters a situation that needs judgment, it can hand the issue to the owner or another authorized human rather than making up an answer.

Specialized job features

DJ and radio

A DJ bot can run a real radio stream, take song requests, answer “what song is this?” from verified now-playing information, make announcements, handle dedications, speak between songs and keep the stream running separately from the visible avatar.

Live Sammy stream.

Music library management

Owner-triggered rescans can rebuild the music library, remove duplicates, clean metadata, repair file naming and rebuild the playable catalog. The system is designed to report real progress instead of pretending a scan finished when it did not.

Event hosting and schedules

Bots can work from schedules, event information and timed cues. A host can greet, announce, promote an event, help the crowd and coordinate with other staff rather than acting as an isolated chatbot.

Sales, rentals and tours

The platform has separate features for sales knowledge, leads, rentals, rental interest, tours, venue information, directions and product knowledge. A customer can build a sales or leasing bot without turning every bot into a salesperson.

Moderation and support

Roles can record support cases, moderation incidents and status changes. A security or manager bot can observe, de-escalate and involve a human instead of being given unlimited power over residents.

Polls, trivia and tips

The platform includes optional poll, trivia and tip-goal features for venues that want interactive entertainment or fundraising-style goals. These are modules, not requirements for every bot.

Private hiring interviews

SageBell can interview applicants by IM, ask common and role-specific questions, ask sensible follow-ups, keep a complete transcript, record strengths and concerns, and prepare a neutral assessment for the owner. If an applicant asks a hiring-policy question Sage cannot verify, she can escalate it to a human and learn the verified answer for later interviews.

The interview system deliberately avoids asking about protected or irrelevant personal traits.

Autonomous advertising scout

AlloySteel (“Steel”) can travel around looking for advertising opportunities, inspect boards, learn different board workflows, record locations, observe traffic, score the quality of a location, avoid duplicating another scout’s territory, plan campaigns and place ads when the workflow and spending rules allow it.

Paid advertising uses configurable L$ controls and keeps an audit trail so the bot does not blindly pay the same board twice.

Advertising proof and tracking

The advertising system records the venue, region, position, board, score, price, rental period, placement method and placement state. It also supports a placed-ads page and campaign/event tracking rather than treating “I clicked something” as proof that an ad is actually running.

Ministry and sermon bots

The platform can run Christian ministry roles with Scripture-grounded conversation, sermon/radio functions and specialized behavior. Individual ministry bots can be stationary or roaming, with boundaries on where they may approach people and when donation requests are allowed.

Owner phone control

The owner can talk with Sammy by phone. Ordinary callers only get conversation, while an authenticated owner call can inspect live bot information, control bot lifecycle, diagnose problems and use the same bounded server-management tools used in an operations session.

Proactive owner calls

Sammy can perform read-only improvement reviews and, when something important is found, place an approval-only call to the owner. Authentication and explicit approval are separate: simply proving who answered does not authorize a change.

Visual observer

A separate Second Life viewer can act as the fleet’s “eyes.” It can be moved to a relevant region, capture what is actually on screen and help answer questions about appearance, signs, objects and spatial relationships when ordinary Second Life data is not enough.

In-world objects and notecards

SLAIBot can communicate with scripted Second Life objects. A central notecard/canon system lets verified venue information be loaded from in-world notecards so multiple bots can learn the same official facts instead of each bot carrying a different guess.

Shared venue and event knowledge

Property facts and event calendars can be synchronized across the fleet. This allows multiple bots to give the same verified answer about a venue, event or location.

Emergency weather relay

The fleet includes a tightly filtered emergency-weather relay for truly severe hazards. It is designed to deduplicate repeated alerts and limit how often it interrupts people rather than turning every weather bulletin into bot spam.

Current SLAIBot lineup

This is the present Phat Cats / PhatLand installation. Other customers can build different roles from the same platform.

Running

Sammy — DJ / host

Sammy is the primary DJ and AI host at Phat Cats. She handles conversation, music requests, verified now-playing answers, announcements, radio, venue questions, memory, movement/facing, dancing, profiles, outfits and owner operations. She is also the main phone-facing bot.

Running

Phoenix — co-DJ / club host

Phoenix works with Sammy at Phat Cats. He stays at his assigned stage position, faces the crowd, uses a stationary dance, trades short on-air banter with Sammy and can occasionally introduce verified songs while Sammy remains the primary music controller.

Running

Sharon — DJ at The Bricks

Sharon is the DJ at The Bricks on PhatLand. She has her own isolated identity, database, state, music and radio while sharing the same general SLAIBot abilities. She can take requests, announce songs, chat with guests and operate independently from Sammy.

Running

Sally — club host

Sally hosts The Bricks. Her job is to greet guests, answer venue questions, help people waiting for Phat Cats and keep The Bricks and the Phat Cats ballroom clearly distinguished.

Running

Rannels — PhatLand greeter

Rannels greets people around PhatLand and The Bricks, gives directions, helps with venue and rental questions, can conduct tours and can move or face guests when the job calls for it.

Running

Giuseppe — Phat Cats front-desk greeter

Giuseppe stands at the ballroom front desk, greets residents, answers questions, gives directions and is configured to remember people and their profiles so repeat guests do not always feel like strangers.

Running

AlloySteel (“Steel”) — advertising scout

Steel is the promotions worker. She searches for ad locations, evaluates traffic, learns boards, records what she finds, places ads where allowed and reports real operational status such as where she is, what she has visited and what has been placed.

Running

SageBell — hiring manager

Sage works from the hiring office. She privately interviews applicants, answers verified job questions, asks the owner when she does not know a policy, keeps the interview record and produces an owner-facing assessment. The final hiring decision remains human.

Running

RevivalMan — roaming ministry bot

RevivalMan is a roaming Christian revival preacher with a deliberately theatrical personality. His movement and outreach are restricted to approved areas, and he is required to disengage when someone does not want the interaction.

Configured, currently switched off

Bill and Joyce — ministry partners

Preacherman “Bill” and PreacherLady “Joyce” are configured as Christian ministry partners with conversation, Bible teaching and sermon/radio capabilities. Their main worker services are currently intentionally not running.

Test / observer role

Roxie — test and vision helper

Roxie is used as a test avatar and visual-observer helper rather than a normal public employee. She is useful for proving new behavior before it is promoted to production bots and for visual tasks that require a real Second Life viewer.

The bots can work as a team

Bot-to-bot messages

Bots can privately send information to another bot instead of forcing every conversation through the owner.

Fleet memory

The owner can give one bot, several bots or the entire fleet an important fact and optionally give that fact an expiration date.

Roundtable discussions

Selected bots can discuss a topic in sequence, with later bots seeing the earlier responses. This is useful when different roles should contribute different perspectives.

Coordinated public chat

The owner can make one or more bots say exact text in local chat, immediately or on a short schedule, without changing their normal personalities.

Cross-bot job handoffs

One bot can hand a job to the bot responsible for it. For example, Phoenix can hand a song request to Sammy instead of pretending to be the primary music controller.

Friend and DJ banter

There are separate coordinators for short, bounded bot-to-bot social exchanges and Sammy/Phoenix DJ banter. They are intentionally limited so the bots do not fall into endless conversations with each other.

Jobs the factory already understands

RoleTypical abilities
DJConversation, memory, music requests, radio, announcements, movement, facing, dancing and venue knowledge.
Club host / event hostGreetings, announcements, crowd interaction, venue help, movement, facing and dancing.
Greeter / receptionist / conciergeGreeting, venue information, directions, tours and human escalation.
Salesperson / store assistantProduct knowledge, current web answers, lead collection and human handoff.
Rental or land agentRental information, sales, directions, tours, promotion and teleport help.
Customer supportConversation, memory, product knowledge, support cases and escalation.
Venue manager assistantHosting, announcements, venue information, movement and selected operational controls.
Security / moderatorObservation, de-escalation, incident reporting, movement/facing and escalation.
Hiring managerPrivate interviews, memory, verified job knowledge, applicant records and owner escalation.
Preacher / ministry hostConversation, Scripture-grounded teaching, announcements, optional radio/sermon functions and event hosting.
Advertising scoutMovement, web/world context, ad discovery, traffic scoring, promotion, placement workflows and controlled spending.
CustomStart with conversation and add only the capabilities the job needs.

Truth, privacy and control rules

No fake live facts

Current song, location, venue state, advertising status, schedules and similar facts are supposed to come from real live data. If the system cannot verify something, the bot should say so rather than inventing it.

Private information stays private

Private IM information and owner-only information are not supposed to become public room chatter, radio banter or casual answers to other residents.

Owner-only controls stay owner-only

Residents can talk to a bot without gaining the ability to reboot servers, restart avatars, spend money, change configurations or issue owner commands.

Human decisions stay human when appropriate

Sage can assess an interview but does not hire someone by herself. Moderation and support can escalate. Advertising spending is bounded. Proactive changes require explicit owner approval.

Each customer bot is isolated

Factory-created bots get separate credentials, database/state, logs, paths, allowed regions, resource limits and dashboard access so one customer bot is not simply sharing another bot’s private runtime.

Changes are supposed to be proven

The platform uses live acceptance checks for important actions. “The service started” is not automatically treated as proof that the avatar is in the correct place or that a feature works in Second Life.

What a customer can configure

  • Second Life avatar identity
  • Display name and aliases
  • Male/female voice or custom voice
  • Job and job instructions
  • Allowed regions and venue assignment
  • Starting position and optional target position
  • Stationary position anchor and facing direction
  • Movement, dance and teleport permissions
  • Memory and conversation abilities
  • Web, profiles and outfit access
  • Music library source
  • Radio/stream settings
  • Announcements and music requests
  • Sales, rentals, tours or product knowledge
  • Promotion and moderation abilities
  • CPU and memory limits
  • Private customer dashboard login
  • Whether the avatar starts immediately after the build
  • Human escalation rules
  • Specialized role modules

Not every bot gets every feature. That is intentional. A front-desk greeter does not need autonomous advertising spending, and an advertising scout does not need to control the ballroom radio. SLAIBot is built around assigning the right abilities to the right job.

How a new bot is built

1. Choose the employee

Pick the avatar, name, job, venue and abilities.

2. Give it boundaries

Choose allowed regions, movement rules, memory, resources, owner/manager permissions and any specialized tools.

3. Give it job knowledge

Add verified venue facts, products, events, policies, music or other information needed for the role.

4. Build an isolated runtime

The factory creates the bot’s separate state, credentials, database, services, logs and optional radio/music setup.

5. Prove the avatar works

If the avatar is started, acceptance includes real Second Life login and location checks rather than only checking files on a server.

6. Manage it without rebuilding

Owners can later change position anchors, selected configuration and lifecycle state without creating the bot from scratch.

Pricing and plans

Pricing is not currently published as a one-size-fits-all number because a simple greeter and a full DJ/radio or advertising bot are very different systems. A serious inquiry can be priced around the avatar, job, venue, radio/voice needs, specialized features and level of management required.

Ask about a venue bot

Live proof and owner controls

Public health · Owner control dashboard

The dashboard is authenticated. Internal credentials, private memory and customer secrets are not public documentation.