Move three
Three roles inside one rulebook. Not three tools with handoffs.
Funnel One is a GTM platform for running a B2B funnel under one set of rules, from first touch to closed-won. Move three puts everyone inside those rules. Marketing, sales and RevOps are three jobs on one funnel rather than three systems joined at the edges — and the same is true of your AI workers, who sit in the same org chart, under the same manager chain, with the same owner field on the same records.
One method, three jobs
The handoff stops being an event.
Marketing
You hand over an MQL and lose sight of it, then argue about lead quality with no evidence six weeks later. Here the record does not change systems at the handoff, so the trail does not stop. The lead you sourced keeps one continuous history to closed-won.
Sales
You work a record whose stage means the same thing it meant upstream. When a stage asks for something before you can enter it, it asks at the moment of the move and gives you the control to answer, rather than sending it back to you on Thursday.
RevOps
You own the rules instead of being them. Stage conditions, required fields, backward-move policy, the reason list, who is in which routing pool — all of it is configuration you change without an engineer, and all of it applies to every path a record can take.
One org chart
An AI worker has a manager, a role and working hours.
There is one workers table and one row per worker. A worker is a person or an AI, never both, and the database enforces that. Each one carries a role, a function, a manager, a working window and an autonomy setting. Records point at whichever kind owns them, through the same field. There is no parallel AI console, no separate permissions model and no second history — which is why nobody has to reconcile two versions of what happened to an account.
- Autonomy is a setting on the worker, not a plan you buy. Suggest, act with approval, or act alone. Move a worker up when it has earned it, and back down when it has not.
- Working hours apply to both. An AI worker’s window is a field on the worker, and the SLA clocks that count against it count in the owner’s working hours rather than wall time.
- Budgets are per worker. A daily token budget and a daily call-minute budget, both optional, both on the worker row.
| Worker | Role | Reports to | Autonomy | Owns |
|---|---|---|---|---|
| Priya Raman | AE | Dan Okafor | — | 41 |
| Ada | SDR | Dan Okafor | Acts with approval | 27 |
| Marcus Hale | AE | Dan Okafor | — | 38 |
| Rowan | Research | Priya Raman | Suggests only | 0 |
| Dan Okafor | Sales manager | — | — | 6 |
The proof
When an AI worker moves a record, it calls the same function a rep’s click calls.
This is the version of the claim that is hard to copy. It is not that we have written rules for AI agents; it is that there is nowhere else for an AI worker to act. The capability that moves a company calls the same stage-move function the human route calls. The capability that changes a pipeline stage calls the same field-patch function the human PATCH calls. Neither has a flag to skip the gate. One path, one answer, one history.
Every action an AI worker can take is registered, permission-gated and executed through one dispatch point. Before it runs: a daily cap, a permission check against the actor built from the session rather than from anything the model produced, a feature flag, an assertion that a tenant context is open, and — for anything destructive or in bulk — a confirmation token that a human has to redeem first. Afterwards, one audit row, including for every denial.
- Owner assigned Pass
- Qualification recorded Pass
- Meeting confirmed by owner Blocked
The limit
Our AI workers execute inside rules. The rules are yours.
We are not promising judgement. An AI worker does not decide what “qualified” ought to mean, does not invent a stage condition and does not overrule one. It works inside a rulebook a person wrote, at an autonomy level a person set, and its moves are refused on exactly the same terms as anyone else’s.
Questions
Do we have to use the AI workers?
No. The workforce model is one table with a type column, so an org with no AI workers has a roster of people and nothing changes. Everything on this page about managers, roles, working hours, owner fields and refused moves is true of a purely human team. The AI part is what happens when you add one, not a condition of the rest working.
How do we control what an AI worker is allowed to do?
Three ways, and they stack. Autonomy is a setting on the worker: suggest only, act with approval, or act alone. Permissions are the same permission model your people are under, resolved from the role rather than from a separate AI policy. And anything destructive or done in bulk needs a confirmation a person has to give before it executes. Every attempt is written to an audit record, including the ones that were refused, so “what did it do” and “what did it try” are both answerable.
Move three
One org chart. Both kinds of worker.
No second system, no second permissions model, no second history to reconcile. Add an AI worker and it appears in the same table, under the same manager, inside the same rules.