From Assistants to AI Employees: Designing Agents That Own a Role, Not a Task

Theme 1: Four things that separate assistants from AI employees (~01:20–01:24)

She opens by acknowledging that "AI employee" can be a provoking term — why put these things into roles like human employees? Ema coined it back in 2023 and designed against these four first principles:

Her aside lands well: "I think we've all apologized for our AI's errors at times — I'm sorry, that was an AI error, I should have checked that better."

One counter-intuitive statistic: on Ema, builders build roughly 50% conversational and 50% API-triggered AI employees — an even split by construction. But more than 90% of actual invocations are automated. Her analogy: you don't ping a junior employee or intern every time; after a point they're just doing things, getting progressively more autonomous.

Theme 2: Platform architecture (~01:25–01:29)

Bottom to top:

• Deployment: multi-cloud and on-prem (Azure, GCP, and others), with data residency.
• LLM layer — EmaFusion: none of their enterprise customers want to deal with model leaderboards or re-decide weekly which model is doing well on a task they care about. EmaFusion takes ownership of keeping the latest models available and, depending on the task the AI employee is performing, promises the best accuracy at the lowest cost and latency.
• Builder platform: a library of pre-trained domain-specific agents — for instance a data-extraction agent for pulling deduplicated, accurate structured data out of a 500-page document containing contradictions and duplications. A generative workflow engine lets you compose those agents alongside deterministic steps, because sometimes you don't want AI (granting someone access to a new system should follow a fixed sequence). And Ema Autopilot generates those deterministic steps for you — you just check the outputs, so no coding required.
• Integration layer: MCP is supported, but she notes Ema built its own tool protocol before MCP existed — faster, more constrained, simpler to set up — so builders get the choice. Most start with MCP because it's already there, but you can bring any API: REST, SFTP, SOAP, whatever.
• Governance: built in. Interaction happens through dashboards, chat, APIs, voice, or generative UI.
• Pre-configured suites across all these layers for employee experience, sales, and customer support.

Customers and scale: founded 2023, serving Fortune 2000 clients, mostly automating HR, IT, and finance roles end-to-end. Thousands of AI employees in production and hundreds of external builders. 100% of their AI employees change state in real systems — they essentially don't have "draft me an email and I'll copy it over myself" use cases. Many companies use Ema as a single pane of glass rather than opening ten tabs, and that pane can be Slack or Teams, because it's an employee and you talk to it where you already are.

Named cases: Wipro (live with 240,000 employees globally for employee-experience questions), Artico (a top US executive search firm; 67% reduction in time-to-hire), Prime Therapeutics (healthcare; thousands of prior authorizations processed in the background), and Hospital for Special Surgery in NYC (patient appointment scheduling).

Theme 3: Their recommended process for building an AI employee (~01:32–01:37)

Ema has three kinds of builders: their own builder team (especially for very non-technical clients like healthcare), partners such as Wipro and KPMG whose builders are trained on Ema and take use cases to market, and customers building for themselves with Autopilot. All three are advised to run the same scoping:

1. Discover and scope. What does the role actually require? Decompose the job into tasks and decide which to do with AI, which deterministically, and which to keep with a human. She calls out a recurring failure: getting a use case without an actual test dataset, so the builder invents test data as they go — while not understanding the business process. Get past examples.
2. Integrations. For production use cases they always recommend using the APIs directly. MCPs work but are slower and consume more context, hence more expensive. Systems with neither fall back to browser use, plus retrieval to improve context. Then break the work into smaller agents so they're easier to evaluate and maintain, and so maintenance can be delegated to different teams.
3. Human-in-the-loop checkpoints. Easier in regulated industries, because some decisions AI simply cannot make — clinical decisions, or financial market decisions like placing an order. But even elsewhere, find where human judgment is key: in recruiting, "you do not want agents to be recruiting end to end." Her design rule is the sharpest thing in this section: put the human boundary at the final act step where state changes, not at the think step — let the AI employee do everything up to the point where a human has to act, so they can read its notes and decide.
4. Train the agent to ask. Teach it to proactively raise human-in-the-loop requests when it's confused.

Theme 4: The live demo (~01:37–01:47)

The plan was three AI employees: sourcing (searching real candidates via Apollo), screening (to demonstrate human-in-the-loop — after shortlisting someone, a human approves before anything is sent), and an orchestrator, because "if you have 100 AI employees, you don't want humans remembering what each one does or whom to go talk to. Nobody wants to deal with routing in their heads." A recruiter or hiring manager talks to one point of contact.

Worth recording from the demo:

• She pasted the whole requirement into Ema Autopilot, approved the plan, and it built the integration, the AI employees, generated test CVs and job descriptions, and produced an eval dataset on its own. Autopilot is a harness with hundreds of tools spanning Ema's product infrastructure — governance, builder, and UI layers — and it accepts your own tools and skills, which is how a firm like KPMG brings decades of finance knowledge while the agentic platform knowledge comes from Ema.
• Failures get learned. Self-correction is retained first for that user and then across the whole company. She says this noticeably improves stickiness over a few months, especially with customer-supplied tools: agents may not know how to use them at first, but "four or five people use it, and for the next hundred people it's going to work well."
• Pasting an API key is deliberately impossible. You cannot hand Autopilot a key and have it wire things up. They do PII and sensitive-data obfuscation at source — the moment you put it in the chat it's obfuscated, and that's what flows downstream. She contrasts this explicitly with "a lot of other harnesses where people just paste API keys and that actually works end to end."
• Three shapes of AI employee: chat; dashboard employees invokable via apps, APIs, or schedules (the source of that 90% of invocations); and the orchestrator. The screening employee in the demo sat paused for human review, releasing fit scores and the drafted email only after sign-off.

Theme 5: Q&A (~01:48–02:12)

The Q&A was denser than the presentation. By topic:

Pricing (~01:48, ~02:10). Usage- and outcome-based. For many AI employees they're selling outcomes: per sales proposal, per customer support ticket, per employee-experience query. It does not depend on tokens and isn't cost-based pricing — it's about what you would pay a person in that job and how much faster you're making them, so different jobs cost very differently. Billing metrics are highly configurable and instrumented in tandem with the customer. The alternative is straight usage: someone buys a million credits and builds whatever they want.

Measuring ROI (~01:50). For cost-center use cases it's straightforward — fewer hours and less involvement from the humans who used to do the task. For productivity cases they start with a prediction: in 2024 the prediction was 15% faster over the course of the year; studies a couple of months in found people were 3x faster, even those tenured ten years in the role. You also look at the outcome — 20% more sales proposals with the same headcount.

Processes that change over time (~01:51). Two kinds. Predictable large changes — prior-authorization clinical policies change annually with a publish date — are fairly self-serve: talk to Autopilot, use Ema's versioning, run your evals, push. Unpredictable real-world drift — customers started asking new kinds of questions in the last couple of weeks — is caught by Ema scanning audit logs to identify improvement opportunities; Autopilot recommends changes with eval data showing it's actually better and won't regress past use cases, and a human signs off on deployment. Both are automated processes.

Live Zoom/Teams call integration (~01:53). They haven't done live call tracking. They process transcripts right after the call; the use case hasn't come up for them yet.

Granularity of control / reward functions per agent (~01:53–01:55). She agrees people want control at the most granular step, and says that's precisely why you have AI employees rather than one universal agent doing everything. Each AI employee usually has a different person managing and training it, with distinct roles — builder, admin, reviewer, onboarder — and those permissions are reflected in the system. Evals run at the AI-employee level, and you don't have to be technical: your control surface is specifying the use case. Business users do this non-technically ("here are last year's tickets, I want at least this performance across them"); technical users bring eval beds. Within an AI employee, some are free-form with no workflow, while others break into smaller blocks — and the same evals can run at block level, e.g. measuring and improving only how well the AI employee works with Apollo.

Slack / Teams (~01:55). Yes, and it's how many customers use them. Wipro uses Teams; another customer embeds an SDK as a floating icon on an internal website. All three are channels, and non-technical people can now set this up in about ten minutes.

Why multi-cloud (~01:56). Sensitive finance and healthcare customers want on-prem, deployed where they already are, and air-gapped — Ema cannot talk to any system including the web or any external API. Customers sit on GCP or Azure, so they were multi-cloud from day one. Dozens of customers are on SaaS and genuinely don't care: "it's like setting up Notion for yourself."

Enforcing data RBAC for the asking employee (~01:57). Yes. Integrations support two connection types: shared service auth, where access is identical regardless of who asks; and user-level auth, which most use cases should use. The first time you ask something requiring a call into, say, ServiceNow, it asks you to log in, and from then on answers come back under your credentials. That restricts what information you get and leaves an audit log in the downstream system: this person requested this information, and it was served to them via an Ema agent.

Largest scale and workflow duration (~01:58). She has personally seen 300–400 AI employees in a single tenant in a single customer deployment. But she stresses it's in people's interest to break them up — back to who maintains this, who's responsible for it staying up to date and following the process. Breaking them apart buys better governance and management. Some workflows run multiple days: a new vendor procurement might carry ten approvals — but the agent is quick; you're stuck waiting on the humans doing the approvals. Other use cases are much faster. (She declined to share cost figures.)

How do you make an AI employee proactive (~02:00). She opened a test tenant to show it, while noting "nobody actually looks at these screens — you just talk to Autopilot; this is like looking at the code." Supported triggers: webhooks, having AI employees poll your systems, connecting directly to systems with conditions ("when there's a new lead added to Salesforce, go figure out if they're a good candidate for us"), monitoring inboxes, and schedules ("every morning I want an email that does X"). Setting each up is as simple as sending a sentence.

Repetitive work and pre-built code recipes (~02:01). Yes — code can be represented as part of workflows. But her recommended path is more interesting: don't spend months setting this up. Start with an empty tenant and zero AI employees, working with Autopilot for every task; as it figures out what's repetitive, it starts codifying — building agentic AI employees or writing and maintaining straight code, based on real usage and feedback.

Task automation or true business-process outsourcing (~02:02). The questioner noted the positioning implies whole-process outsourcing while the examples look task-oriented. Her answer: the end state for every contract and project is role-focused — it lands on a single interface you can talk to, or a single automation, that does the entire job across all the tasks. But adoption starts slower: you can build an AI employee that does everything end to end, and the blocker is always the humans collaborating with it. So in practice they launch task by task — sourcing, then screening CVs, then scheduling interviews, then onboarding the candidates you liked and managing the offer letter — which helps the recruiting team warm up and learn to work with AI agents. Start with a task, expand to the full gamut of the role.

Human-to-AI-employee ratio (~02:04). Creating AI employees on Ema is easy and cheap, and you're only charged when you're actually getting value, so people create plenty of automations. But Ema works only with very large companies, so the ratio skews: a 200-person recruiting team might need about 20 AI employees, with very high usage each — thousands of invocations per day. They don't optimize for number of agents.

How a big GM- or Bank-of-America-scale deal actually runs (~02:05). Either someone at Ema or a partner acts as the agentic transformation expert responsible for the AI employees working well and launching the first time. That's a deep discovery process: not just workshops with the buyer and team lead, but sitting in the room with the person doing the job and shadowing them for hours and days, plus reviewing all their past work examples from the last year, before writing the definition. Once the process is well defined, there isn't much left — throw it into Ema Autopilot and in a few hours it's built and tested. Her conclusion is the line worth keeping: "You don't have to know about Ema to launch impactful stuff in Ema. You have to know a lot about the business process. That's the expertise you need." Which is also why many customers then want to build themselves: if you're just going to put it in Autopilot, I can do that — I'm the expert on this recruiting process.

Employee resistance (~02:06). She says that resistance was much more common two or three years ago — "why do you want me to evaluate AI samples when this will probably affect my own role?" That has changed a lot in the last couple of years: everyone has realized you need to be faster and AI-equipped to stay at the top of your job and your industry, and that adopting AI makes you more valuable and better at the work. Now they see excitement — people want to be the ones training it and to understand how it works. She calls this the rise of citizen developers: people who have never written a line of code and want to bring AI into their jobs.

Skills versus AI employees (~02:11, final question). A skill is a less powerful version of an AI employee, and the platform supports them. Their benefit is a strong template marketplace making it easy to share things with the right people inside your own company — which works for AI employees too. But AI employees are much more complex: they have their own memory, mix deterministic and agentic steps, and are evaluated very specifically for their use case. Most people taking something live want all those tabs — how many people used it, where it went wrong, where it can improve, automated improvement help. So although skills exist, most people prefer using AI employees directly.

Quotes

"You have to be a little scared — you have to govern everything yourself. … And I think we've all apologized for our AI's errors at times." (~01:21)

Under the assistant model, governance accountability quietly lands on the user — the starting point for the whole AI-employee design.

"You put a human boundary at the final act step where you're changing the state, and you don't do it at the think step." (~01:36)

The most portable human-in-the-loop design rule in the session.

"You don't have to know about Ema to launch impactful stuff in Ema. You have to know a lot about the business process. That's the expertise you need." (~02:06)

Her complete answer to where the deployment bottleneck sits.

"You can build an AI employee that does everything end to end, but the blocker is always the humans that are collaborating with that AI employee." (~02:03)

The most candid line of the session: the constraint isn't agent capability, it's organizational pace.