Picture two restaurant menus. The first lists forty dishes, all with lovely descriptions. You order three, and the waiter comes back twice to say that one “isn’t on tonight.” The second menu is shorter, and it has a small note at the bottom: “Coming this season: a tasting menu and a lunch set. Ask us when.” Everything above that line is in the kitchen today.
Both restaurants might have equally good chefs. Only one of them lets you plan dinner.
Software for AI employees is mostly the first menu right now. The category is full of confident sentences: it handles your calls, it runs on its own, it plugs into everything. Some of those sentences describe products in production. Some describe a demo. Some describe a plan. They are written in the same present tense, so a buyer cannot tell them apart.
We think the most useful thing a vendor can do is label every capability with its tense, and we think you should demand that from anyone you buy from, including us.
Three labels, and what each one means
Every capability we describe gets one of three labels: live, being built, or direction. Here is what we mean by each.
- Live. It works in the product today, and you could try it this week. If it has limits (who can use it, which plan, how long something waits), the limits are written down next to it.
- Being built. Work is under way, but you cannot use it yet. It might change shape before it ships.
- Direction. We intend to go there. There is no date, and it could change.
The difference matters most when money changes hands. A demo is allowed to show direction; that is what demos are for. A contract, a rollout plan or a promise to your own customers needs what is live. When those two get mixed up, the gap is usually found by your team, after the purchase, at the worst moment.
Our own labels, as they read today
Here is a sample of what our own pages say is live and what is not, so you can see the labels in use. Each line comes from our public docs or an earlier post.
- Approvals. A workflow can pause at an approval step you add, and a workspace owner approves or rejects before it continues. That is live. What is not built: pausing risky actions by default. An approval only happens where someone has added one (approval node, and why the line matters in supervised or autonomous).
- Approval notices. Owners get an in-app notice when an approval is waiting. Email notice is not available: the setting exists, but no email is sent yet.
- Phone calls. An AI employee cannot place or receive a real phone call today. Telephony is on our roadmap as direction.
- Starting on its own. A workflow can start on a schedule today. Starting because something happened in another system (an event trigger) is not built; it is direction.
- A database of your own. Workspaces share the platform’s database, and every request is scoped to the signed-in workspace. A dedicated database per workspace is designed but not currently offered (pricing).
- Certification. We hold no independent security certification today (is my company data kept separate?).
- Billing. We report usage; we do not bill it yet. There is no public rate card and no self-serve plan change (pricing: what is not built yet).
- Hiring a ready-made role. A workspace owner can hire a role we have listed. Nothing appears until we list one, so today it is available by invitation. Moving an existing hire to a newer version of its role is not built.
None of these lines is flattering on its own. Together they are a map: you can see where the edge of the product is, and plan around it.
What labels cost us, and what you get
Labels make us sound less impressive, and we accept that trade. A page that says “not built” next to “phone calls” will lose some readers to a page that simply says “voice AI for every channel.”
It costs us in a second way too. Once you label things, you also have to correct yourself in public when a label was wrong. Our changelog carries correction entries for exactly that: on one occasion our own docs pages implied that a dedicated database was available. It was not, so we said so in the changelog and fixed the pages. That is uncomfortable to publish. It is also the only way a label stays worth reading.
What you get in return is the ability to plan. If you know approvals are something you add, you add them where they matter, instead of assuming a safety net that is not there. If you know email notice is missing, you decide who checks the in-app notices and when. If you know phone calls are direction, you do not promise them to your customers in next quarter’s launch.
How to test any vendor’s claim
Ask one question about every claim: “Is that in production for a customer today, and can I try it?” It is polite, it is fair, and it sorts the menu quickly.
A few follow-ups help when the answer is vague:
- “Show me it working on our data, not on the demo account.” A demo account is built to make a feature look good. Your own messy records are the real test.
- “What are the limits?” Everything live has limits: a time-out, a plan, a size, a role that is allowed to use it. A vendor who cannot name the limits of a feature may not have shipped it.
- “What happens when it fails?” A live feature has a failure path someone has thought about. Direction usually does not. Our post on what the customer sees when an AI employee fails shows what that looks like in practice.
- “Can I have your not-built list?” Every honest product has one. If a vendor says there is nothing on it, that tells you something.
Notice that none of these questions needs technical knowledge. They are the same questions you would ask a builder, a caterer or a new supplier.
Five questions to ask before you sign
Before any contract for an AI employee, get written answers to these five. Ask us too.
- Which of the capabilities in this proposal are live today, and which are being built or direction? Ask for the labels next to each line, not a general statement.
- What are the documented limits of each live capability? Who can use it, on which plan, and what happens at the edge.
- What does the AI employee do alone, and what waits for a person, and which person? If nobody in your company is named as being in charge of it, fix that before you start.
- Where is the not-built list, and when was it last updated?
- Where will I see it when a label changes? A public changelog, a roadmap page, release notes: something you can check without asking a salesperson.
If a proposal survives those five, the menu is probably the second kind.
Our commitment: the line moves in public
When a capability moves from direction to live, it shows up in our changelog first, and the roadmap is updated to match. The changelog tracks what has actually shipped, as it lands. The roadmap describes where we are heading, and it says so at the top in plain words: direction, not a commitment. Nothing on it is promised for a date.
We would rather you read “not built” on our pages than discover it in your rollout. And if one of our labels turns out to be wrong, we want to hear about it, so we can correct it in the same public place.
Related reference docs
- Changelog: what has shipped, as it lands, including corrections to our own docs
- Roadmap: engineering direction (telephony, event triggers, supervision), not a commitment to dates
- Pricing & plans: the limits each plan enforces today and what is not built yet
- Approval node: the approval step you add, who decides and what happens on expiry
If you are weighing up an AI employee and want our labels for your use case, tell us which work you’d hand over first and we will tell you which parts are live and which are not.