Ema

Full confirmed and rebuilt from a boilerplate rubric string, and the estate is larger than the July prose claimed. THE COUNTS ARE PUBLISHED AND THERE ARE TWO OF THEM: the homepage states 250+ PREBUILT INTEGRATIONS under CONNECT EVERY SYSTEM, and separately 1,000+ PREBUILT CONNECTORS. BUILD ANYTHING ELSE IN MINUTES. The two figures are not reconciled anywhere and are recorded as the vendor's own rather than resolved — the likeliest reading is applications against endpoints or actions, but nothing says so.

Either way this is among the largest connector estates in the sublane. THE SYSTEMS NAMED ARE THE ENTERPRISE SYSTEMS OF RECORD, not a logo wall of SaaS conveniences: the EmaFusion post lists Salesforce, ServiceNow, SAP, Workday and Snowflake, and the homepage adds Teams and Slack. ServiceNow, SAP and Workday are the three hardest connectors to build in this category and the three a buyer in HR, IT or finance actually needs, which is exactly the segmentation Ema sells to.

THE AGENT ACTS THROUGH THEM, WHICH IS THE THRESHOLD CLAUSE: Ema is positioned as completing tasks end to end rather than answering questions, taking actions across HR, ticketing and collaboration platforms after reading documents, logs, data and policies for context. The published workflow example is concrete — check a customer record, draft a reply, route it, send it — which is reading and writing in someone else's system within one run.

BUILD ANYTHING ELSE IN MINUTES is a customer-extensible connector path, so the estate is not bounded by what Ema has shipped. ONE FACT, ONCE, AND THE DIRECTION TEST IS THE WHOLE POINT ON THIS RECORD: these connectors are Ema reaching outward, which is tool-calling and belongs here.

Ema's own inbound API for EmaFusion is the opposite direction and is spent on Extensibility, where it holds only Partial — a thousand outbound connectors is not evidence that the platform is callable, and conflating the two would inflate that cell. The channels these same systems provide, Teams and Slack and voice, are arrival surfaces and are spent on Triggers. CONFIDENCE 0.85, capped because ema.ai/integrations was not opened within budget, so both counts are stated rather than enumerated and the discrepancy between them is unresolved.

Sourceema.ai homepage Connect every system section with /blog EmaFusion postread 2026-09-12

Full confirmed and rebuilt from a boilerplate rubric string. THE ORCHESTRATOR IS A NAMED COMPONENT WITH A STATED MECHANISM: the Generative Workflow Engine, described on the vendor-published Microsoft Marketplace listing as what lets ANY TEAM CREATE POWERFUL AI AGENTS CONVERSATIONALLY, WITHOUT WRITING A SINGLE LINE OF CODE.

What makes it orchestration rather than generation is that it does not follow a fixed script: it interprets a request, decomposes it into steps, and generates the workflow to carry them out across systems, adjusting as results return. A customer inquiry becomes read the message, check the customer record, draft a reply, route it for approval, send it — five steps, three systems and a human turn in the middle.

THE AUTHORING SURFACE IS CUSTOMER-FACING AND THE HOMEPAGE STATES ITS FOUR PHASES: BUILD — FROM PLAIN-LANGUAGE INTENT TO A WORKING AI EMPLOYEE IN MINUTES; OPTIMIZE; PERSONALIZE; SCALE. Build from intent means the buyer composes the sequence, not the vendor. SCALE IS THE CLAIM THAT EVIDENCES LONG-RUNNING EXECUTION: ENGINEERED FOR ENTERPRISE SCALE — THOUSANDS OF WORKFLOWS, MILLIONS OF RUNS. Runs at that volume are unattended by definition, and the employee experience suite describes rollout across 200,000+ employees.

AGENT-TO-AGENT COORDINATION IS DOCUMENTED, which is the clause that separates Full from the single-agent-many-steps Partial held across sublane 4: Ema's AI Employees are described as collaborating WITH BOTH HUMANS AND OTHER AGENTS to deliver business value. Multiple agents working one problem, with people as participants rather than only as operators.

THE HUMAN TURN IS A FIRST-CLASS STEP RATHER THAN AN INTERRUPTION — configurable approval chains sit inside the workflow, which means a sequence can pause on a person and resume, the shape that distinguishes orchestration from a pipeline. Spent on Human oversight; named here because a process that survives a pause is holding state across a gap it does not control. ONE FACT, ONCE: the approval chains go to HITL, the audit trail to Observability, the connector writes to Integrations, the model selection per step to Model.

Counted here: the decomposition, the multi-agent coordination and the state held across long-running runs. CONFIDENCE 0.85, capped because no page describes retry or failure handling, and the GWE's own page was not reached. Return item: ema.ai/autopilot.

Sourceema.ai homepage One platform every workflow section, with the Ema listing on Microsoft Marketplace and /blog AI Employee Builder postread 2026-09-12

Full confirmed and rebuilt from a boilerplate rubric string, though on thinner evidence than the other Fulls on this record and the confidence reflects that. GROUNDING IS STATED AS A POSITIONING CONTRAST, WHICH IS THE STRONGEST FORM ON THE HOMEPAGE: PERSONALIZE — GROUNDED IN YOUR ENTERPRISE CONTEXT, NOT GENERIC TEMPLATES. Ema is drawing the same line this axis draws: an agent answering from the company's own material rather than from general knowledge.

THE EMPLOYEE EXPERIENCE PAGE DESCRIBES WHAT THAT CONTEXT DOES, and it is the most concrete grounding evidence on the estate: EMA USES ORGANIZATIONAL CONTEXT AND POLICY-BASED REASONING TO PERSONALIZE EVERY RESPONSE. IT UNDERSTANDS VARIATIONS BY REGION, EMPLOYEE BAND, AND DEPARTMENT, DELIVERING ACCURATE AND COMPLIANT ANSWERS EVERY TIME.

Resolving an answer differently by region, band and department means the retrieval layer holds structured organisational facts, not just documents — an HR agent that gives a French employee the French leave policy is traversing a model of the organisation. THE CORPUS IS FED BY THE CONNECTOR ESTATE: 250+ prebuilt integrations across Workday, ServiceNow, SAP, Salesforce and Snowflake, with the platform reading documents, logs, data and policies for context before acting.

Systems of record rather than a document dump, which is what makes policy-based reasoning possible. PERMISSIONED RETRIEVAL IS IMPLIED BY THE ACCESS MODEL: RBAC/ABAC permissions resolving to individual actions bound what any given answer can draw on. Spent on Security; named here as the boundary retrieval operates within. WHY 0.75 RATHER THAN HIGHER, AND THE GAP IS SPECIFIC.

Persistence is the discriminator on this axis, and no first-party page read describes a maintained store: no index, no knowledge graph, no sync model, no freshness or citation behaviour. Ema markets an Enterprise Context Graph described as deep permissioned memory across an organisation's data, systems and processes — but the only place that language was found is the company's LinkedIn page, which is an excluded source and is NOT the basis for this grade.

The Full rests on the grounding claims above; the architecture behind them is asserted on a source the bar refuses. THAT IS THE RETURN ITEM AND IT IS PRECISE: any first-party page naming the Enterprise Context Graph would both confirm this cell and settle Memory, which currently fails the four-clause rung for the same reason. ONE FACT, ONCE: the connectors are spent on Integrations; EmaFusion on Model; the auto-refinement loop on Eval.

Sourceema.ai/employee-experience and homepage Personalize sectionread 2026-09-12

Full confirmed and rebuilt from a boilerplate rubric string. THE GATE IS NAMED, CONFIGURABLE, AND STATED AS A TRUST PILLAR RATHER THAN A FEATURE FOOTNOTE: IMMUTABLE AUDIT TRAILS — EVERY AGENT DECISION CAPTURED AND TRACEABLE, WITH CONFIGURABLE HUMAN-IN-THE-LOOP APPROVAL CHAINS. Two words carry it. CONFIGURABLE means the customer decides where the gate sits rather than accepting a vendor default, which is the autonomy dial this axis rewards.

CHAINS means more than one approver in sequence — a multi-step approval path, which is what an enterprise deploying an agent into payroll or finance actually needs and which almost nothing else in this sublane offers. THE GATE SITS INSIDE THE WORKFLOW, NOT BESIDE IT.

Ema's published workflow example runs read the message, check the customer record, draft a reply, ROUTE IT FOR APPROVAL, and send it — the approval is step four of five, so the sequence pauses on a person and resumes.

A hold placed mid-run on the agent's own action, before an irreversible send, is the Full bar as this review has applied it: brief-ai cleared it on a no-autonomous-send commitment, coworker-ai on approval gates addable to any workflow, and Ema clears it on approval chains configurable into any workflow. THE BOUNDING LAYER UNDERNEATH IS UNUSUALLY FINE: RBAC/ABAC governance with PERMISSION LEVELS FROM ORGANIZATION TO INDIVIDUAL ACTION.

Permissions resolving to an individual action mean an agent's authority is capped per operation rather than per user or per data source, so what an approved action can reach is bounded even after approval. That is spent on Security as the access half and named here as the boundary the gate operates within. PII DETECTION AND REDACTION IS A SECOND, AUTOMATIC GUARDRAIL that fires without anyone approving anything, stripping sensitive data before it reaches a public model.

Also spent on Security; named because it is a control on agent behaviour rather than on user access. THE COLLABORATION FRAMING IS CONSISTENT ACROSS THE ESTATE: AI Employees are described as collaborating with human colleagues and working alongside them at checkpoints, and the marketplace listing calls the whole thing a centralised agentic control plane to monitor, govern and audit.

WHAT CAPS THIS AT 0.9: no page describes an escalation path when an approver does not respond, a timeout behaviour, or an override audit. ONE FACT, ONCE: the immutable trail in the same sentence is a record rather than a gate and is spent on Observability.

Sourceema.ai homepage Trusted by design section with the Ema listing on Microsoft Marketplaceread 2026-09-12

Full confirmed and rebuilt from a boilerplate rubric string, and this is one of the strongest Security cells in the review. THE ATTESTATION HALF IS EIGHT CERTIFICATIONS DEEP, published as a badge wall under the heading GOVERNANCE, PRIVACY AND COMPLIANCE AREN'T ADD-ONS. THEY'RE THE FOUNDATION: SOC 2 Type II, ISO 42001, ISO 27001, ISO 27017, ISO 27701, CSA STAR, EU AI Act and GDPR, with a trust centre published at trust.ema.ai. The vendor-published Microsoft Marketplace listing states the same set independently and adds NIST.

ISO 42001 IS THE ONE WORTH NAMING — it is the AI management-system standard rather than a general infosec one, and it is the certification that speaks to how an agent platform governs its models rather than how a company secures its servers. Alongside EU AI Act alignment and ISO 27701 for privacy information management, this is a compliance posture built for the specific risk of autonomous agents rather than a generic enterprise checklist.

THE CUSTOMER-FACING CONTROL HALF IS NAMED AND GRANULAR: RBAC/ABAC GOVERNANCE — PERMISSION LEVELS FROM ORGANIZATION TO INDIVIDUAL ACTION, WITH PII DETECTION AND REDACTION. Attribute-based access control alongside role-based is unusual and it is the right control for this product: permissions that resolve to an individual ACTION, not merely to a user or a data source, is what bounds an autonomous agent mid-run.

PII detection and redaction before data reaches a public model is a second, distinct control, and it matters because EmaFusion routes across a hundred external models by design — the redaction layer is what makes that routing safe. Both halves of the conjunction, comfortably. SUPPORTING SURFACES: a published Data Processing Addendum, a Privacy Policy and a Privacy Centre in the footer, plus encryption described as top-tier on the EmaFusion post and customisable private models for customers who will not use public ones at all.

ONE FACT, ONCE, AND THE STANDING RULE BITES HARD HERE: on-premises and air-gapped delivery are deployment properties and are spent entirely on Deployment, never on Security. The immutable audit trail is spent on Observability and the human-in-the-loop approval chains on Human oversight. Counted here: the certifications, the RBAC/ABAC model and PII redaction. CONFIDENCE 0.9, capped only because trust.ema.ai was not opened within budget, so the certificates are named on the vendor's own page rather than read from the portal.

Sourceema.ai homepage Trusted by design section, /employee-experience, /blog EmaFusion post and the Ema listing on Microsoft Marketplaceread 2026-09-12

CORRECTED UP FROM PARTIAL, and the July cell offered no reason for the Partial — the same boilerplate string as the other thirteen. THE CLAIM IS THE RIGHT OBJECT AND IT IS STATED IN ONE SENTENCE: IMMUTABLE AUDIT TRAILS — EVERY AGENT DECISION CAPTURED AND TRACEABLE, WITH CONFIGURABLE HUMAN-IN-THE-LOOP APPROVAL CHAINS. Four properties in eleven words, and each is what this axis asks for.

Immutable answers whether the record can be edited after the fact, which is the property an auditor actually tests and which almost nothing else in this sublane claims. Every agent DECISION, not every user action, puts the object squarely on the agent rather than on the customer's estate — the wrong-object failure that held eight records at Partial in this review. Captured and traceable means a reconstructable path, not a dashboard.

THE GOVERNANCE FRAMING IS CORROBORATED SEPARATELY AND BY A DIFFERENT SURFACE: the vendor-published Microsoft Marketplace listing describes A CENTRALIZED AGENTIC CONTROL PLANE THAT LETS YOUR TEAM MONITOR, GOVERN, AND AUDIT EVERY AI APPLICATION ACROSS THE ENTERPRISE. Monitor, govern and audit as three distinct verbs over a fleet of agents is an observability surface at estate level, which matters for a platform selling fifty-plus AI employees running in parallel.

THIS SITS ON THE FULL SIDE OF THE LINE THIS REVIEW HAS SPLIT ON REPEATEDLY — rippling, serval, siit, workable, zinghr and coworker-ai cleared it on a named action log, against gem, deputy, humanly, juicebox, manatal, nova-recruiter, seekout, workleap, brief-ai, circleback and dust held at Partial for having output or usage visibility with no record of activity. Ema publishes the record of activity and calls it immutable.

THE ATTRIBUTION LAYER UNDERNEATH IS REAL: RBAC/ABAC governance with PERMISSION LEVELS FROM ORGANIZATION TO INDIVIDUAL ACTION means actions are attributable to an identity at the granularity the trail needs. WHAT CAPS THIS AT 0.8: the trail is asserted rather than described. No page states its retention period, whether it is exportable or queryable, whether it captures the agent's reasoning or only its decisions, or whether it is gated to a tier.

For a platform whose own pitch is enterprise governance, that detail should exist somewhere and was not reached. ONE FACT, ONCE: the human-in-the-loop approval chains in the same sentence are a gate rather than a record and are spent on Human oversight; the RBAC/ABAC model on Security. Return items: trust.ema.ai and support.ema.ai.

Sourceema.ai homepage Trusted by design section, with the Ema listing on Microsoft Marketplaceread 2026-09-12

Partial confirmed and rebuilt from a boilerplate rubric string, tested explicitly against the four-clause GOVERNED RUN STATE rung ruled at Q78. CLAUSE 1, AGENT-WRITTEN AS A CONSEQUENCE OF ITS RUNS: PARTIALLY MET, AND THE PART THAT IS MET IS REFUSED SEPARATELY. The homepage promises OPTIMIZE — CONTINUOUS ANALYSIS AND AUTO-REFINEMENT, SO PERFORMANCE COMPOUNDS OVER TIME, and the EmaFusion post says these agentic systems KEEP LEARNING FROM THEIR CURRENT AND PAST ENVIRONMENTS, GET BETTER WITH TIME.

Learning from past environments is agent-written accretion, and it is absorbed learning, which is None by standing rule wherever it appears. Compounding performance is not retrievable state. CLAUSE 2, SCOPED: MET, and well — RBAC/ABAC governance with permission levels from organisation to individual action, plus single-tenant isolation available up to fully air-gapped. Whatever is retained is bounded by an unusually fine permission model. CLAUSE 3, PUBLISHED LIFETIME WITH AN EXPIRY OR PURGE PATH: FAILS.

No retention period, expiry, purge route or deletion path for agent state is stated anywhere on the pages read. A Data Processing Addendum and Privacy Centre exist in the footer and neither was reached. CLAUSE 4, A FIRST-PARTY READ AND WRITE SURFACE OVER RETAINED STATE: FAILS. The only API claimed anywhere is for EmaFusion, the model layer, and nothing describes reading or editing what an agent has retained.

WHY PARTIAL RATHER THAN NONE: the immutable audit trail captures EVERY AGENT DECISION and makes it traceable, which is retained, attributable, run-level state even though it is a record rather than a working memory — that satisfies the attributable-to-a-run limb of the disjunctive guide, alongside scoping. Two limbs plus a refused learning claim is above database-as-memory and below the four-clause rung. THE ITEM THAT WOULD SETTLE THIS IS NAMED AND IS THE SAME ONE FLAGGED ON KNOWLEDGE.

Ema markets an ENTERPRISE CONTEXT GRAPH described as deep permissioned memory across an organisation's data, systems and processes, which if published first-party with a lifetime and an access surface would likely clear all four clauses at once. The only source carrying that language is the company's LinkedIn page, which is excluded outright, so it is recorded here as a lead and explicitly NOT counted. CONFIDENCE 0.7. Return items: any first-party page naming the Enterprise Context Graph, plus ema.ai/dpa and the privacy centre for retention.

Sourceema.ai homepage Optimize and Trusted by design sections, with /blog EmaFusion postread 2026-09-12

CORRECTED UP FROM PARTIAL. The July cell carried no reason at all — its basis was the boilerplate string "Agent Features research report + JSON Feature Rubric", identical across all fourteen cells — and the Vendor record's deploymentOptions field read ["SaaS", "VPC"] while its own prose claimed on-premises and air-gapped support. The field was wrong and the prose was right.

A NAMED CUSTOMER ENVIRONMENT OPTION IS THE FULL BAR AND EMA STATES IT AS ONE OF THREE HEADLINE TRUST CONTROLS: ON-PREM AND AIR-GAPPED DEPLOYMENT — RUN EMA ENTIRELY IN YOUR ENVIRONMENT, FULLY ISOLATED WHEN YOU NEED IT. Not a footnote in a security FAQ; it sits in the Trusted by design block on the homepage beside the certification wall. The vendor-published Microsoft Marketplace listing states the same three-way choice independently: DEPLOY IN YOUR CLOUD, ON-PREMISES, OR IN AN AIR-GAPPED ENVIRONMENT.

A page published by the vendor on a marketplace is first-party under the standing rule, so this is two first-party statements rather than one. THE SOLUTION PAGES REPEAT IT RATHER THAN LEAVING IT ON THE HOMEPAGE: the employee experience page states THE PLATFORM SUPPORTS ON-PREMISE AND AIR-GAPPED DEPLOYMENTS, so the claim survives outside the marketing headline. AIR-GAPPED IS THE CLAUSE THAT MATTERS AND IT IS RARE.

Fully isolated means no egress, which for an agent platform routing across a hundred models is a hard architectural commitment rather than a configuration flag — it implies the private and customer-supplied models named elsewhere on the estate can carry the workload alone. Ema markets itself as the only agentic platform supporting it; that superlative is not counted, but the capability is.

ONE FACT, ONCE, AND THE DISTINCTION MATTERS ON THIS RECORD: the certification wall — SOC 2 Type II, ISO 27001, ISO 42001, ISO 27017, ISO 27701, CSA STAR, EU AI Act, GDPR — is spent entirely on Security. Sovereign or isolated delivery is a deployment property and never a security control, which is the standing rule this lane leans on hardest. Counted here: the customer environment options alone.

WHAT IS NOT PUBLISHED, AND CAPS THIS AT 0.85: no named region list for the hosted option and no residency selection surface for cloud customers, so a buyer who wants managed SaaS in a specific region has no published answer — only the on-prem escape hatch. Nothing describes what an air-gapped install excludes. Return item: trust.ema.ai.

Sourceema.ai homepage Trusted by design section, /employee-experience, and the Ema listing on Microsoft Marketplaceread 2026-09-12

Full confirmed and rebuilt from a boilerplate rubric string. THE CATALOGUE IS NAMED AND SIZED: the vendor-published Microsoft Marketplace listing states that ENTERPRISES CAN DEPLOY FROM EMA'S LIBRARY OF 50+ PRE-BUILT AI EMPLOYEES OR BUILD THEIR OWN USING EMA'S GENERATIVE WORKFLOW ENGINE. A library a buyer deploys from, with an explicit alternative of building instead, is the selectable-unit standard this axis asks for. A marketplace page published by the vendor is first-party under the standing rule.

THE UNITS ARE ROLES, WHICH IS WHY THE REMOVAL TEST PASSES CLEANLY. Ema organises them by function and publishes a page per area: Employee Experience, Customer Experience, Finance Operations, Sales and Marketing, Professional Services, Intelligent Actions, plus vertical pages for Healthcare and Insurance. Remove the finance AI employee and the recruiting one is untouched; remove customer support and payroll still runs.

These are not stages of one pipeline serving one buyer — they are different jobs for different departments, which is the workleap and coworker-ai shape rather than the seekout shape where the named items turned out to be steps of a single sequence. THE VERTICAL PAGES ARE THE Q39 CONTENT-PACK SHAPE: Healthcare and Insurance are per-market configurations, and the employee experience page describes Ema understanding VARIATIONS BY REGION, EMPLOYEE BAND, AND DEPARTMENT with policy-based reasoning — a rule set that does work when selected.

THE LEAD PRODUCT IS ITSELF A PACKAGED ROLE: Ema Recruiter is marketed as a named AI employee rather than a capability, and the homepage segments the whole platform three ways as AI EMPLOYEES FOR HR, IT, AND FINANCE. BUILDING IS THE ALTERNATIVE, NOT THE ONLY PATH, which is the discriminator that separated this from dust earlier in the sublane: dust publishes a gallery of the customer's own agents, empty on day one, while Ema ships fifty-plus of its own that a buyer adopts before building anything.

ONE FACT, ONCE: the Generative Workflow Engine as an authoring surface is spent on Orchestration; the connectors that let a deployed AI employee act are spent on Integrations. CONFIDENCE 0.85, capped because the fifty-plus library is a stated count rather than an enumerated directory, and no individual AI-employee page was opened within budget. Return item: ema.ai/personas.

SourceEma listing on Microsoft Marketplace, with ema.ai homepage and solution navigationread 2026-09-12

CORRECTED DOWN FROM FULL, and the correction is about what is documented rather than about what the product does. The July Full rested on the boilerplate rubric string and cannot be checked. CHANNEL COVERAGE IS REAL AND IS THE HALF THAT CARRIES PARTIAL: CONNECT EVERY SYSTEM — 250+ PREBUILT INTEGRATIONS. ONE DIGITAL FRONT DOOR. WORKS WITH TEAMS, SLACK, VOICE OR MORE. Three arrival surfaces named, and voice is the notable one — few records in this sublane reach a spoken channel at all.

The employee experience suite is described as reaching a workforce of 200,000+, which only works if the agent meets people where they already are rather than in a separate console. ONE DIGITAL FRONT DOOR is the vendor's own framing for consolidating those surfaces. WHAT IS NOT DOCUMENTED IS THE TRIGGER MODEL ITSELF, and that is why this cannot hold Full. No page read enumerates scheduled runs, cron cadences, event subscriptions, webhook triggers or condition-based firing.

The homepage describes Ema as an ALWAYS-ON INTELLIGENT BUILDER and claims THOUSANDS OF WORKFLOWS, MILLIONS OF RUNS, both of which imply automated invocation at scale without naming what starts a run. The published bar wants events, schedules and multiple channels; one of the three is evidenced and the other two are implied by scale claims.

AN IMPLICATION IS NOT A DOCUMENTED TRIGGER, and the standing rule cuts both ways here: I am not asserting absence from a failed pass, I am declining to leave a Full standing on a rubric string when the first-party estate does not support it. Recorded as Partial with the gap named rather than held at Full or dropped to None.

THE PAGES THAT WOULD SETTLE IT ARE NAMED IN THE SITE NAVIGATION AND WERE NOT REACHED: ema.ai/intelligent-actions and ema.ai/autopilot, either of which is where a trigger catalogue would live on this estate, plus support.ema.ai. This cell moves back to Full on one of them. ONE FACT, ONCE: the 250+ integrations counted here are arrival and delivery surfaces; the same estate as systems the agent transacts against is spent on Integrations, and what a triggered run then does on Orchestration. CONFIDENCE 0.65, medium, and the medium is honest — this is a documentation gap on a live product rather than a confident finding about the product.

Sourceema.ai homepage Connect every system sectionread 2026-09-12

Full confirmed and rebuilt from a boilerplate rubric string. Ema's whole product identity is its model layer, and it clears the bar on both the routing half and the customer-control half. VENDOR-SIDE ROUTING IS THE PRODUCT, NOT A FEATURE: EMAFUSION COMBINES 100+ MODELS IN REAL TIME — FUSING THE BEST ONES FOR EACH TASK, NOT JUST PICKING ONE.

The distinction the vendor draws is worth recording, because it is a step beyond the routing this axis usually sees: selection picks one model per request, fusion blends outputs from several. The EmaFusion post describes it as a small language model that BLENDS OUTPUTS FROM OVER 100 LLMS — PUBLIC, PRIVATE, SPECIALIZED, OR OPEN-SOURCE — OPTIMIZING FOR ACCURACY, COSTS, AND LATENCY, choosing the model-mix by task complexity rather than using one expensive model for everything.

WHAT CARRIES FULL RATHER THAN PARTIAL IS CUSTOMER CONTROL, STATED PLAINLY: YOU CAN ALSO BRING YOUR OWN MODELS (BYOM), with customisable private models named separately. Disclosed multi-provider routing alone is the middle rung; a customer supplying their own model is the top one. The record's own July prose said the same thing and had nothing behind it; it does now.

FAULT TOLERANCE IS A THIRD PROPERTY AND IT IS A REAL ONE: IF ONE MODEL HAS AN OUTAGE OR SLOWS DOWN, EMAFUSION SWITCHES TO OTHERS AUTOMATICALLY. NO LOCK-IN. Automatic failover across providers is an availability control that only a genuinely multi-provider architecture can offer, and it is evidence the routing is live rather than a configuration screen.

THE COMMERCIAL FRAMING CORROBORATES IT: the homepage sells NO TOKENMAXXING alongside outcome-based pricing, and the vendor claims EmaFusion beats the best single model at up to 20x lower cost. Those comparative claims are unaudited and are recorded rather than counted; the capability they describe is what grades.

ONE FACT, ONCE: the 250+ integrations are tool-calling and are spent on Integrations; the API clause is spent on Extensibility; PII redaction before data reaches a public model is a security control and is spent on Security, even though it exists because of the routing. CONFIDENCE 0.9.

Sourceema.ai homepage EmaFusion section with /blog EmaFusion postread 2026-09-12

CORRECTED DOWN FROM FULL. The July Full rested on the same boilerplate string as every other cell and cannot be checked; against the first-party estate the surface is real but thin, and it is thin in a specific way. WHAT IS DOCUMENTED IS ONE CLAUSE ABOUT ONE COMPONENT: JUST PLUG EMAFUSION INTO YOUR STACK THROUGH OUR API, OR USE EMA'S BUILT-FOR-HUMANS UI. That is an API, it is first-party, and it makes the platform callable from outside — enough for the middle rung and not enough for the top one.

Note what it covers: EmaFusion is the model-fusion layer, so the sentence establishes that a customer can route inference through Ema programmatically. Nothing states that the AI Employees, the Generative Workflow Engine or the agent estate are callable, which is the surface this axis is actually about on an agent platform. THE FULL BAR ASKS FOR A DOCUMENTED API OR SDK FOR THE VENDOR'S OWN PLATFORM, AND DOCUMENTED IS THE WORD DOING THE WORK.

No endpoint reference, no authentication model, no SDK, no OpenAPI specification, no CLI and no developer host was located anywhere on the estate. There is no docs subdomain in the site navigation or footer; the nearest surface is support.ema.ai, listed as FAQs.

NO MCP ANYWHERE, which is worth stating plainly on a 2026 enterprise agent platform and is unusual against the rest of this sublane — circleback ships MCP on its free tier, dust hosts native and remote MCP servers, coworker-ai runs an MCP server, brief-ai runs one at a named endpoint. Ema mentions it nowhere on the pages read. ONE FACT, ONCE, AND THE DIRECTION TEST DECIDES THE BIG NUMBER ON THIS RECORD: 250+ PREBUILT INTEGRATIONS and 1,000+ PREBUILT CONNECTORS are Ema reaching outward into the customer's systems.

That is outbound tool use and it is spent entirely on Integrations. A large connector count is not evidence that the platform is callable, and conflating the two is the error that would keep this cell at Full for the wrong reason. THE LIMITATION IS NAMED HERE RATHER THAN LEFT IN THE NOTE, as every Partial must: one API claimed for the model layer, nothing published for the agent layer, and no reference for either. CONFIDENCE 0.7. Return items: support.ema.ai, ema.ai/integrations and ema.ai/emafusion, none reached within budget — any one could take this back to Full.

Sourceema.ai/blog EmaFusion post with the homepage and site navigationread 2026-09-12

Partial confirmed and rebuilt from a boilerplate rubric string, and the rung is right for a reason the July cell could not have recorded. WHAT SUPPORTS PARTIAL IS A LIVE OPTIMISATION LOOP ON THE AGENT'S OWN PERFORMANCE, WHICH IS THE CORRECT OBJECT: OPTIMIZE — CONTINUOUS ANALYSIS AND AUTO-REFINEMENT, SO PERFORMANCE COMPOUNDS OVER TIME, listed as one of the four phases of the platform beside Build, Personalize and Scale.

That is Ema measuring how its own AI Employees perform and adjusting them, not measuring the customer's workforce — the wrong-object trap that held manatal, seekout, workleap and coworker-ai at None on this axis. The distinction matters and it is why this record sits a rung higher than most. WHY NOT FULL, AND THE LANE BRIEF DRAWS THE LINE PRECISELY: a pre-deployment harness or a CONTROLLED post-deployment optimisation loop is Full, and a live metric on operations is Partial.

Nothing published makes this loop controlled or its result readable. There is no test environment, sandbox, dry run, holdout, A/B comparison, versioning or rollback of an agent configuration, and above all no readable verdict — no score, no pass rate, no before-and-after comparison a customer can inspect. AUTO-REFINEMENT WITHOUT A PUBLISHED RESULT IS THE PROBLEM RATHER THAN THE VIRTUE. The agent changes itself continuously, and a buyer has no documented way to see what changed, why, or whether it improved.

For a platform certified to ISO 42001, an AI management-system standard whose whole subject is governing model behaviour, an unreadable self-optimisation loop is a conspicuous gap rather than an unlikely one. THE ADJACENT CLAIM IS REFUSED: agentic systems that KEEP LEARNING FROM THEIR CURRENT AND PAST ENVIRONMENTS, GET BETTER WITH TIME is absorbed learning, which is not an evaluation surface on any reading and is refused on Memory as well.

And the immutable audit trail records what an agent DID, not whether it was RIGHT — that is spent on Observability, and the two together mean behaviour is reconstructable but not scored. CONFIDENCE 0.7. Return items: ema.ai/autopilot, which is where a control loop would be described on this estate, and trust.ema.ai, since ISO 42001 conformance implies documented evaluation practice somewhere.

Sourceema.ai homepage One platform every workflow section with /blog EmaFusion postread 2026-09-12

None confirmed and rebuilt from a boilerplate rubric string, with confidence raised from 0.6 because the absence is now observed across the vendor's own estate rather than asserted by a rubric. THE BUYER TEST IS MEANINGLESS FOR THIS PRODUCT, WHICH IS THE CLEANEST FORM OF THE GRADE: how often does Ema break when a UI element changes is not a question anyone would ask of a platform whose reach is 250+ prebuilt integrations and 1,000+ prebuilt connectors into Workday, ServiceNow, SAP, Salesforce and Snowflake.

Every path in and out is a connector or an API. A third party redesigning its interface does not touch it, and the architectural pitch — BUILD ANYTHING ELSE IN MINUTES — is about adding connectors, not about driving screens.

NONE OF THE THREE MODALITIES APPEARS across the homepage, the employee experience page, the EmaFusion post, the AI Employee Builder post or the vendor-published Microsoft Marketplace listing: no hosted or local browser, no desktop session, no remote or local computer control, no RPA, no recorder and no extension acting on a page. THE ONE ADJACENT ITEM IS A CHANNEL, NOT A MODALITY, and is refused explicitly: the homepage lists VOICE alongside Teams and Slack under Connect every system.

Voice is a way a person reaches an AI Employee, the same class as a chat channel, and it is spent on Triggers. Speaking to an agent is not the agent operating an interface. AIR-GAPPED DEPLOYMENT CUTS AGAINST IT RATHER THAN TOWARD IT, and the point is worth recording because the phrase RUN EMA ENTIRELY IN YOUR ENVIRONMENT could be misread as local machine control.

It is the opposite: an isolated installation of the platform inside the customer's network, which is a deployment property spent on Deployment, and a fully isolated environment is the least likely place to find an agent driving external web interfaces. THE CATEGORY THIS PRODUCT OCCUPIES EXPLAINS THE ABSENCE.

Ema sells AI Employees for HR, IT and finance in regulated enterprises certified to ISO 42001 and the EU AI Act; the work is transactional against systems of record where an API exists for everything, and screen automation would undercut the auditability the platform is sold on. CONFIDENCE 0.75, capped because ema.ai/intelligent-actions was not reached and is the one page whose name suggests an action modality.

Sourceema.ai homepage, /employee-experience and the Ema listing on Microsoft Marketplaceread 2026-09-12