Ema

Internal support is where large organisations lose an extraordinary amount of time to questions that already have answers. How much leave do I have. Why was my expense rejected. Who approves this. When does the new policy apply.

Those questions are answered by people who could be doing something else, and the answer is almost always sitting in a system the asker cannot navigate or does not know exists.

Ema addresses that, and the thing that separates it from the dozens of companies with the same idea is not the agents. It is what surrounds them — because an agent that reads HR records and acts on them is a governance problem before it is a productivity one, and Ema has clearly worked that out.

What Does Ema Deploy?

• Agents for HR, IT and finance covering recruiting, onboarding, benefits, performance and internal support requests.
• EmaFusion combines 100+ models in real time, with automatic failover if a provider has an outage — a genuinely sensible architecture.
• 1,000+ prebuilt connectors and 250+ integrations, reached through Teams, Slack or voice rather than another portal.
• Eight compliance certifications including ISO 42001 for AI management, plus on-premise and air-gapped deployment.
• Governance is built in: RBAC and ABAC controls, immutable audit trails, and human-in-the-loop approval chains.

The Compliance List Is The Actual Product

Ema states SOC 2 Type II, ISO 42001, ISO 27001, ISO 27017, ISO 27701, EU AI Act alignment, GDPR and CSA STAR, alongside on-premise and air-gapped deployment, RBAC and ABAC governance, immutable audit trails and human-in-the-loop approval chains.

That is a longer list than most enterprise software carries, and in this category it is the differentiator rather than a hygiene factor. An agent operating in HR touches salary, performance reviews, medical accommodations and disciplinary records — the most sensitive data an employer holds, regulated separately in most jurisdictions.

Two of the certifications are worth singling out. ISO 42001 is the AI management systems standard, which is specifically about how an organisation governs AI rather than how it secures data — exactly the question a board now asks and which SOC 2 does not answer. ISO 27701 covers privacy information management, which matters when the data is about employees.

EU AI Act alignment is the forward-looking one. HR use cases including recruitment and performance evaluation are classified as high risk under that regulation, with obligations around transparency, human oversight and documentation. A vendor that has thought about this before customers ask is ahead of most.

Air-gapped deployment closes the remaining case for defence, government and heavily regulated buyers where nothing leaves the network at all.

Certifications are also what separate this tier from lighter agent tools. A support-focused platform such as Forethought solves a narrower problem without having to clear a security review of this depth.

An agent that reads performance reviews and medical accommodations is a governance problem before it is a productivity one.

Human-In-The-Loop Is Not Optional Here

Ema states approval chains with human-in-the-loop and immutable audit trails, and for HR agents specifically this is the mechanism that makes deployment defensible.

The reason is that decisions about employment have legal consequences. A recruitment agent that screens candidates is making a decision with discrimination exposure attached. A benefits agent that determines eligibility is affecting someone's healthcare.

Under the EU AI Act and comparable emerging rules, high-risk uses require meaningful human oversight — not a rubber stamp, but a person with the authority and information to override.

Immutable audit trails are the evidentiary half. When someone challenges a decision, you need to show what the system did, on what basis, and who reviewed it. A log that could have been edited is not evidence.

The practical implication for a buyer is to design the approval chains before deployment rather than after. Which decisions may an agent take alone? Which require review? Who has authority to override, and do they have the information to do it meaningfully? The technology supports all of this; the operating model is yours to write.

Does Combining 100 Models Beat Using The Best One?

EmaFusion is claimed to combine 100+ models in real time, beat the best single model at up to 20 times lower cost, and fail over automatically if a model has an outage.

The failover claim is the one to take most seriously and it is rarely discussed. Model providers do have outages, and an enterprise support agent that stops working because a single vendor is degraded is a production incident affecting every employee. Automatic failover across providers is genuine operational resilience, and single-model architectures simply do not have it.

The cost argument is also structurally sound. Most enterprise questions are easy — checking a leave balance does not need a frontier model — and routing simple queries to cheap models while reserving expensive ones for hard cases is exactly how you would design this if cost mattered.

The 20 times figure is where scepticism belongs. No methodology, baseline or task mix is published, and a cost multiple depends entirely on what proportion of your queries are simple. A workload of trivial lookups would show an enormous multiple; a workload of complex reasoning would show almost none.

Read it as directional rather than as a specification. The architecture is right; the number is marketing, and your own query mix decides what you would actually see.

The multi-model argument is not unique to Ema — coding agents like Zencoder make a version of it too — but it remains far easier to claim than to demonstrate.

• Automatic failover is the most valuable part of multi-model routing and the least advertised.
• Cost savings depend on what proportion of your queries are simple — model that on your own mix.
• Ask which models are in the pool and whether you can exclude any on governance grounds.
• Confirm how routing decisions are logged, since audit trails need to show which model answered.
• Test whether quality holds on your hardest queries, not the easy ones the routing sends cheaply.

A Thousand Connectors Is The Real Barrier To Entry

Ema states 1,000+ prebuilt connectors and 250+ prebuilt integrations, reached through Teams, Slack or voice as one digital front door.

Connector count is the least glamorous and most decisive number here. An HR agent is useless without access to the HR information system; a finance agent needs the expense platform and the ERP. Every one of those integrations is unglamorous engineering against a system with its own permissions model and its own quirks.

That work is also why enterprise agent projects fail. A pilot with three connected systems demonstrates well; production needs thirty, and the twenty-seven remaining are where the timeline goes.

The front-door framing matters just as much. Employees will not adopt another portal — they are already in Teams or Slack all day, and an agent that lives there is used while one behind another login is not.

The questions to press are about depth rather than count. Which specific systems in your stack are covered, does a connector read or also write, and how are permissions inherited? An agent that can see everything in your HR system regardless of who is asking is a data breach waiting for a curious employee.

Connector depth is exactly why incumbents are hard to displace. A platform already holding your CRM data, such as HubSpot AI, starts every one of these conversations several steps ahead.

What Outcome-Based Pricing Actually Means

Ema states outcome-based pricing, with no unused modules and no tokenmaxxing. That is a deliberate positioning against two real problems in enterprise AI purchasing.

Module bundling is the first: buying a suite where you use two of nine components and pay for all nine. Token-based pricing is the second, where cost scales with how verbose the system is rather than with what it achieved, and the vendor has no incentive to make it concise.

Charging for outcomes aligns those incentives properly, and it is the right instinct. The complication is definitional and it is where a buyer should spend their attention.

What counts as an outcome? A resolved ticket, where resolution is judged by whom? An onboarding completed, measured how? An agent that closes a request the employee then re-opens has produced an outcome by one definition and not by another.

This is not a criticism so much as the central term of the contract. Get the definition, the measurement method and the dispute process in writing before signing, because with outcome pricing that definition is the price. Everything else in the negotiation matters less.

Evaluating An AI Employee Deployment

Enterprise agent pilots go wrong by proving the technology works rather than testing whether it works in your systems with your governance.

The bar is step three. Permission inheritance is where agent deployments produce their most serious failures, and it is invisible in a demo.

1. Pick one function and one high-volume question type — leave balances, expense status — rather than piloting all three functions at once.
2. Connect the real systems, not sample data. Integration friction is what you are actually evaluating.
3. Test permissions adversarially: have someone junior ask about a senior colleague's salary and confirm the agent refuses. This is the failure that matters most.
4. Write the approval chain before enabling any agent that takes an action, defining which decisions need human review and who can override.
5. Check the audit trail for a completed request and confirm it records which model answered and who approved.
6. Define the outcome you are being charged for, in writing, and measure your own count against the vendor's on the pilot.