AI agents for meetings and events: what an agent owns, what it can't sign

At Davos 2026, World Economic Forum attendees got an agent called EVA. Salesforce built it on Agentforce, grounded in the Forum’s own data, and it did the unglamorous work: recommend, book, reschedule, or cancel bilateral meetings and sessions, give turn-by-turn wayfinding, and assemble a brief before each conversation. At Davos 2025 the earlier Agentforce deployment answered 99.9% of inquiries and resolved three-quarters of them without a human.

The real prize in meetings and events is not the trip-planner chatbot everyone demos. MICE (meetings, incentives, conferences, and events) is a coordination problem: sourcing a venue, holding a room block, registering attendees, routing their travel, and running on-site logistics for hundreds or thousands of people at once.

My read: the attendee-facing concierge and the planner’s back-office drafting are the work an agent should own, and the two places it must never act alone are the venue contract and the room rate. Sign the wrong attrition clause and you owe a hotel five figures for rooms nobody slept in. Quote a rate the system didn’t confirm and you have promised a price you may have to honor.

Two agents, not one

Group and event work has two very different users, and one agent bolted across both does neither job well. Split them.

The attendee concierge is the EVA pattern. It faces the delegate, the incentive-trip winner, the conference-goer. It answers logistics, recommends sessions, rebooks a meeting, points to the right room, and drafts a personalized agenda. Its job is deflection and experience, the same job as any service agent that shouldn’t invent a fare.

The planner assistant faces your internal team, the meeting planner or the corporate travel manager. It drafts the RFP to candidate venues, compares bids on a rubric, tracks the budget, chases vendor responses, and flags an attrition risk before it bites. Its job is speed on repetitive work that today lives in email threads and a shared spreadsheet.

Keep them as separate agents with separate topics, separate actions, and separate permission sets. The concierge reads attendee data and public event content. The planner reads contracts, budgets, and vendor records. The blast radius of a mistake is different for each, so the guardrails should be too.

What the concierge can own

The attendee agent runs on data you already control: the registration record, the agenda, the room map, the attendee’s stated preferences. Ground it there and it stays useful without inventing anything.

Session and meeting management is the highest-value action. An attendee asks to move a 2pm bilateral to the morning, and the agent checks both parties’ availability, finds a slot, and rebooks it. If you run Salesforce Scheduler, you do not write Apex to find open slots; its standard Agentforce actions read availability, territories, and work rules for you, and the whole build comes down to the running user and the channel.

Wayfinding and logistics are pure retrieval: which room, which floor, when the shuttle leaves, where the incentive-group dinner is. This is grounding against event content, not generation, and it is where hallucination does the least damage as long as the agent quotes the source and says so when it doesn’t know.

Personalized agendas are recommendation over the attendee’s profile and the session catalog. The agent proposes; the attendee accepts. That keeps a human in the loop on the one thing an agent can get subtly wrong, which is what matters to this person.

What the planner assistant can own

The planner side is where the spreadsheet lives, and where an agent buys back real hours.

RFP drafting is the obvious first action. Given an event brief (dates, headcount, room-night pattern, meeting-space needs, budget), the agent drafts a structured RFP and can fan it out to candidate venues through a sourcing integration. Bid comparison follows: normalize the responses onto one rubric, surface the trade-offs, and hand the planner a ranked shortlist instead of eight PDFs.

Budget tracking and vendor chasing are the steady, boring wins. The agent reconciles committed spend against the budget, flags when a food-and-beverage minimum is at risk, and follows up with a vendor who hasn’t responded. None of this requires the agent to decide anything; it requires it to watch and draft.

For the parts that touch systems outside Salesforce, a sourcing platform or a GDS, you do not need to hand-build every integration in Apex. If the service has an OpenAPI spec and a Named Credential can authenticate, External Services turns each operation into an agent action with no code. The planner agent uses that to reach a venue-sourcing API, send an RFP, or read a bid.

The reference architecture

The data model is more custom object than out-of-the-box, because Salesforce ships no “events cloud” that covers this end to end. Build it on primitives you already have.

Model the event itself as a custom object with child objects for room blocks, sessions, and vendor bids. Attendees are Contacts or Leads tied to a Campaign, which gives you registration and response tracking for free. The venue and its sales contact are Accounts and Contacts like any other supplier.

Unify the attendee view in Data 360 when the same person shows up across registration, CRM, and past events. The concierge grounds on that unified profile so it recognizes a repeat delegate instead of treating them as new. Consent matters here, because attendee data is personal data, and an activation has to respect an opt-out the same way any other does.

Coordinate the multi-step, multi-owner parts with Flow Orchestration, which became a standard feature in Spring ‘26. Contract review, budget sign-off, and the hand-off between the planner agent and a human approver are exactly the human-plus-agent-plus-system choreography it exists to run.

Here is a minimal Apex action the planner agent calls to check a room block before it promises anything to an attendee. It reads committed and picked-up rooms from your own records and returns availability. It never invents a number.

public class RoomBlockAvailability {
    public class Request {
        @InvocableVariable(required=true) public Id eventId;
        @InvocableVariable(required=true) public Date stayDate;
    }
    public class Result {
        @InvocableVariable public Integer roomsAvailable;
        @InvocableVariable public Boolean atAttritionRisk;
    }

    @InvocableMethod(label='Check Room Block Availability'
        description='Returns remaining rooms for an event date from committed block records')
    public static List<Result> check(List<Request> requests) {
        List<Result> results = new List<Result>();
        for (Request req : requests) {
            Room_Block__c block = [
                SELECT Contracted_Rooms__c, Picked_Up_Rooms__c, Attrition_Threshold__c
                FROM Room_Block__c
                WHERE Event__c = :req.eventId AND Stay_Date__c = :req.stayDate
                LIMIT 1
            ];
            Result r = new Result();
            r.roomsAvailable = (Integer) (block.Contracted_Rooms__c - block.Picked_Up_Rooms__c);
            r.atAttritionRisk = block.Picked_Up_Rooms__c < block.Attrition_Threshold__c;
            results.add(r);
        }
        return results;
    }
}

The pattern is the load-bearing rule from every travel agent worth trusting: the agent reads the number from the system of record and never generates it. A rate, an availability count, or a contract term that came from the model instead of a record is a liability.

Where the human still holds the pen

Three decisions stay human, and building the agent so it stops at them is the difference between a helpful tool and an expensive mistake.

The venue contract is the first. Attrition clauses, food-and-beverage minimums, cancellation and force-majeure terms, these are commitments with real money and legal exposure attached. An agent can redline, compare, and summarize. A person signs.

Rate negotiation is the second. The back-and-forth with a hotel sales manager over a group rate and concessions is judgment and relationship, and it is where a planner earns their fee. Let the agent prep the planner with comparables; do not let it commit a rate.

The irreversible attendee action is the third. Cancelling a booked room, moving an incentive group’s flights, or changing a VIP’s itinerary is the kind of step a triggered travel agent should draft but never send alone. Route it through a confirmation, the same way you would any high-consequence action.

The gotchas that decide the ROI

Cost is the first. Under Agentforce Flex Credits, actions bill per action, and an event with thousands of attendees each taking several concierge actions adds up fast. Model the credit consumption per attendee before you scale from a pilot conference to your whole calendar, the same discipline as any Flex Credit optimization exercise.

Group booking is a distributed transaction, and that is the second. Flights, rooms, meeting space, and transfers each live in a different system with its own confirmation and its own failure mode, which is the same hard problem tour operators face when no single supplier owns the trip. An agent that books three of four legs and fails the last has created a mess, not a booking. Revalidate before you commit, and design the rollback.

Data quality is the third and the quietest. A concierge grounded on a duplicated attendee record or a stale agenda gives confident wrong answers, and at an event the feedback is immediate and public. The unglamorous work of clean attendee data is what makes EVA look effortless.

Start with the concierge for a single flagship event, measure deflection and satisfaction, then add the planner assistant once the data foundation holds. The vendors specializing in event and group travel are already shipping agentic booking, and the platforms embedding task-specific agents are multiplying this year. The teams that win are the ones that let the agent run the logistics and keep the contract, the rate, and the irreversible move firmly in human hands.

Understanding the basics

What is a MICE or group-travel AI agent?

It is an AI agent applied to meetings, incentives, conferences, and events: the coordination-heavy work of sourcing venues, holding room blocks, registering attendees, and running on-site logistics for groups. In practice it splits into an attendee-facing concierge that handles session booking, wayfinding, and rebooking, and a planner-facing assistant that drafts RFPs, compares vendor bids, and tracks budgets.

Can an AI agent book an event venue on its own?

It can draft the RFP, send it to candidate venues, compare the bids, and prepare the negotiation. It should not sign the venue contract or commit a group rate. Attrition clauses and food-and-beverage minimums carry real financial and legal exposure, so the contract and the rate stay a human decision even when the agent does all the preparation.

How does Agentforce fit event and group travel?

Agentforce provides the agent runtime, topics, and actions. Salesforce Scheduler supplies standard actions for availability and booking, Data 360 unifies the attendee profile for grounding, External Services connects sourcing platforms and GDS systems without custom code, and Flow Orchestration coordinates the approvals. Salesforce’s EVA agent for the World Economic Forum’s 2026 Davos meeting is a live example of the attendee-concierge pattern.

What is the biggest risk in an event agent?

Two things. First, a hallucinated number: a room rate or availability count the agent generated instead of reading from a record, which becomes a promise you may have to honor. Second, cost at scale, because per-action Flex Credit billing multiplies across thousands of attendees. Ground every number in the system of record and model credit consumption before scaling.

Scoping an event or group-travel agent, and drawing the line between what it automates and what your planners still own? Talk to us. Getting an agent to run the logistics without quoting a rate it made up is exactly the work we do.