Skills: availability, booking, waitlist, reviews

An agent becomes operational when it can use a small set of approved tools and show the result. For businesses organized around appointments, reservations, or field visits, the first useful skills are availability, booking, waitlist, and review requests. Each skill should accept clear inputs, return a visible result, and refuse work outside its boundary.

Availability should return a bookable resource

“Who is free?” is not enough. Availability needs the service, duration, location, provider or resource requirement, and requested time range. The result should identify an option that can be booked now, not a loose suggestion from cached hours.

A salon result may include a technician and chair. A clinic result may require both a practitioner and room. A restaurant result needs party size and turn time. A field-service result may depend on territory, skill, travel, and equipment.

If any required resource is missing, the skill should return no valid slot rather than inventing one.

Booking should write once and confirm the result

The booking skill takes the selected option, rechecks it, writes the appointment, and returns the calendar identifier or a clear failure. Rechecking matters because another person or agent may have taken the slot after it was offered.

The conversation should not say “You are booked” until the write succeeds.

Waitlist should work one opening at a time

The waitlist skill begins with a defined hole and an eligible queue. It contacts candidates in an approved order, creates a temporary hold when needed, rechecks availability, and stops when the booking is filled or the deadline passes.

The full operating design is covered in How to design a no-show recovery agent.

Review requests should follow the completed visit

The review skill should trigger only after a visit closes according to the business rule. It asks once, uses the approved listing for that location, and stops around an open complaint or dispute. It should not filter people by predicted sentiment or keep asking until someone responds.

The result should show sent, skipped, failed, or handed off so the team can explain what happened.

Every skill needs an owner and a stop

Tools do not remove judgment. A booking skill should stop on an off-menu request. A waitlist tool should preserve a VIP hold. A review request should pause around a complaint. The owner of that exception must be visible before the tool goes live.

Test the tool result, not the agent’s wording

During a demo, inspect the inputs and outputs directly. Ask for a slot that exists and one that cannot exist. Race two booking attempts against the final opening. Fill a cancellation, then verify the queue closes. Create a complaint and confirm the review request is skipped.

This is the difference between a tool that operates on the book and a conversation that merely sounds capable. How to watch an agent run shows where those tool calls should appear.

Write every skill as a contract

A skill contract defines what the tool accepts, what it returns, what it changes, and how it fails. This keeps business logic out of conversational wording and gives the team something concrete to test.

For each skill, document:

• Required and optional inputs.
• Source of truth for every input.
• Permissions needed to run.
• Side effects the skill may create.
• Success result and stable identifier.
• Refusal and error results.
• Retry behavior.
• Audit fields stored with the run.

The contract should be readable by operations as well as engineering. “Returns available slots” is too vague. “Returns bookable provider, resource, location, start time, end time, and hold eligibility for the requested service” gives the team a result it can verify.

Make availability resource-aware

Availability is usually the most underestimated skill. A free provider does not guarantee a bookable appointment. The skill may need a room, chair, table, device, vehicle, or location that is also available for the full duration.

Model the service first. Include setup, cleanup, travel, processing, or turn time when those affect the next booking. Then query all required resources together.

Return a small set of valid options rather than every open block. The agent can ask a clarifying question when provider preference, location, or service type is missing. If the request remains ambiguous, return no safe option or hand it off.

Availability should never create a reservation by itself unless the contract explicitly includes a temporary hold. Reading and writing are separate capabilities with different risks.

Make booking idempotent

Customers repeat themselves, channels retry, and integrations resend events. The booking skill must prevent one confirmation from becoming two appointments.

Use an idempotency key tied to the conversation, selected option, and confirmation event. Before writing, recheck the slot and search for an existing booking created by the same request. If the previous write succeeded but the response was lost, return the existing record instead of writing again.

The success response should include the calendar record, service, location, provider or resource, start and end time, and any payment or hold state. The agent’s final message should use this returned data.

Treat changes and cancellations as separate skills

Editing an appointment is not simply another booking call. The existing record may have cancellation windows, deposits, protected resources, or downstream notifications.

Create explicit change and cancellation contracts if the agent is allowed to perform them. Define which fields can change, whether availability must be rechecked, what fees or approvals apply, and when a person must take over.

If these tools do not exist, the front-desk agent should collect the request and hand it off. It should not simulate a change by creating a second booking and leaving the first one active.

Give waitlist a state machine

Waitlist is a sequence, not one send action. Useful states include detected, eligible, offered, held, confirmed, expired, closed, and handed off.

The skill should expose the current candidate, hold expiry, and booking state. It must stop when the opening fills, the original slot returns, a person takes control, or the response deadline passes.

Make review requests location-aware

A review skill needs the completed visit, correct business profile, approved message, language, and eligibility state. Multi-location groups should never send a client from one door to another location’s listing because the profiles share a brand name.

Store the request result with the visit so the workflow does not ask twice. If delivery fails, follow the business retry rule rather than starting a new campaign. If an open complaint or dispute exists, stop and route the issue according to policy.

Do not use predicted satisfaction to decide who receives a public review link. The rule should be based on visit completion and explicit exceptions the business can defend.

Use least privilege for every tool

An agent that checks availability does not automatically need permission to cancel appointments or change staff schedules. Grant only the actions required for the job being deployed.

Separate read, hold, write, cancel, message, and administrative permissions. Keep credentials out of prompts and content. Record which agent and run used the permission.

For sensitive actions, require additional confirmation or a person. The goal is not to give the agent broad access and hope the prompt restrains it. The tool boundary should enforce the restriction.

Design predictable errors

Every skill will fail sometimes. The contract should distinguish invalid input, no eligible result, permission denied, conflict, timeout, source unavailable, and unknown error.

These are different operating outcomes. No availability can be explained to the customer. A conflict may trigger a recheck. A timeout should not be described as no availability. An unknown write result requires checking the destination before retrying.

Return errors in a form the agent can handle without inventing a story. Also preserve technical details for the team without exposing them to the customer.

Test contracts with fixtures from the real floor

Create a small fixture set before launch:

1. A valid request with one clear result.
2. A valid request with no result.
3. A request missing a critical field.
4. A resource conflict hidden behind a free provider.
5. A duplicate booking attempt.
6. A tool timeout after a possible write.
7. A protected situation that must hand off.

Run these fixtures whenever service mappings, integrations, or policies change. The conversation can vary, but the tool outcomes should remain stable.

Monitor skill health separately from agent quality

Track call volume, success, refusal, conflict, timeout, retry, and latency for each skill. Then connect those results to corrected bookings and human handoffs.

If availability often returns no result because required resources are missing, fix the source data. If booking conflicts rise during rush hours, inspect hold and recheck behavior. If review requests fail at one location, inspect the profile mapping.

Separating tool health from conversation quality prevents the team from rewriting prompts to compensate for an unreliable action layer.

Add skills only when a job needs them

A front-desk agent may begin with availability and booking. Recovery adds waitlist. Rebooking adds completed-visit context and future availability. Reputation adds review eligibility and location mapping.

Do not expose every skill to every agent. A smaller toolset is easier to secure, test, and explain. Expand when a repeated, approved job requires a new action and the business can define its contract.

Version skills like operating policy

Record a version when inputs, permissions, side effects, failure behavior, or source mappings change. Tag each run with the version it used. This allows the team to verify whether a correction worked and to roll back when a change creates new errors.

Approval should match risk. A wording adjustment may need editorial review. A booking-contract change needs operations and technical review because it can alter the live calendar. A new permission needs an explicit owner.

Keep the previous contract and fixture results with the change record. Do not edit history to make old runs appear as though they used the current rules.

Publish a skill scorecard

For each tool, show volume, success, safe refusal, conflict, timeout, unknown result, retry, and human correction. Add latency only where it affects the customer promise.

The scorecard should lead to a concrete owner. Integration failures go to the technical owner. Missing resources go to operations. Repeated policy handoffs go to the decision-maker. This keeps tool improvement grounded in the layer that can actually change the outcome.

Keep a human-readable tool directory

List every active skill, the agents allowed to use it, its owner, source system, permissions, and last fixture result. Retire unused tools instead of leaving them available for possible future work.