How systems talk
Outcomes
When an AI Employee needs to act
AI Employees are wired to know your business: your business profile, your website, the FAQs you train them on. That is enough to answer questions. But the ones that earn their keep do something. Picture a voice receptionist that looks up the caller in your CRM while the phone is still ringing, greets them by name, books the appointment, and then hands off to a follow-up that texts them an hour later.
None of that is code. It is a few pieces you switch on in the employee's setup, plus one automation that picks up where the call leaves off.
How an AI Employee reaches another system
For the receptionist to greet the caller by name, her setup has to reach into your CRM and pull that caller's record, mid-call. Systems reach each other through a doorway, and the doorway one system opens for another is called an API.
Here is the part that makes this feel out of the box: most of those doorways are already built for you. The CRM, the calendar, the messaging tools all open their doorways to the platform, and you switch them on rather than wire them. You build a new doorway only when you reach a system the platform does not already connect to, and even then you are filling in a form, not writing code.
The pieces you switch on
Three pieces make an AI Employee act, and you meet all three in its setup:
- A capability is a skill you switch on, written as plain instructions: "look up the caller by phone number and greet them by name." The platform calls it exactly that, a capability.
- A tool is how a capability reaches another system through its doorway. The CRM lookup is a tool; so is booking the calendar. Most tools are ready to attach; you add a custom one only for an outside system.
- A trigger is what makes the employee act at all: answering a call, receiving a message.
Switch on a capability, give it the tools it needs, set the trigger, and the employee can do the thing instead of only talking about it.
Two ways systems talk: ask and announce
Once a doorway is open, a system uses it in one of two ways, and the receptionist uses both.
Ask
How it works: you send a question, and the system sends an answer back.
When you use it: to look something up, create a record, or update one.
Example: the receptionist asks your CRM "who is calling from this number?" and gets the caller's record back. This is the API, or request-and-response, pattern.
Announce
How it works: something happens, and the system announces it. Whoever cares reacts.
When you use it: to kick off follow-up work the moment an event happens.
Example: the call ends, and the platform announces it by logging a call activity. It does not know or care who is listening. This is the event, or webhook, pattern.
The difference is who goes first. When the receptionist asks, she goes first, because she wants an answer now. When the platform announces the finished call, it goes first, and whoever was waiting for that news gets to act. What travels between them is small: a package of labeled facts, a name, a number, a time. Not a screen, not a file, just the facts the next step needs.
The hand-off: the employee and the automation
That "whoever was waiting" is an automation, and it is the second half of how work actually gets done.
The receptionist takes the call. The automation does the follow-through. The announcement is the baton passed between them. The moment the call is logged, an automation that was listening for exactly that wakes up and works down its checklist: wait a while, check whether this lead was already contacted, send the text, post a note to the team's chat, and if there is no reply, line up the next touch. Each of those steps reaches another system the same way the receptionist did, through its doorway: the messaging tool to send the text, the team's chat to post the alert, even an outbound-calling tool to try again.
In most businesses, a person is the glue between these steps: someone hangs up, then remembers to text the lead, then updates the account. Here that glue work is automated, so nothing waits on a person remembering. Neither worker does the whole job: the employee handles the live conversation and the judgment inside it; the automation handles the reliable, repeatable follow-through. Together they are the AI Workforce actually doing the thing, not just talking about it.
Putting it together
Watch the whole thing line up on one caller.
Pick one thing you wish an AI Employee could do for a client, start to finish. Name the three pieces: what skill would it need (a capability), what system would it have to reach (a tool), and what would set it off (a trigger)? Then name the one follow-up an automation could handle after. You have just sketched an AI Employee that does the thing, not only talks about it.
Knowledge Check
A few quick questions on the pieces you switch on, ask versus announce, and the hand-off to an automation.