Aigensei vs Enhans (2026)

Stands at F, with the MCP fact now landing here alone rather than being counted on Ext as well. THE INTEGRATION ARCHITECTURE IS PROTOCOL-BASED RATHER THAN CATALOGUE-BASED, and that is the interesting trade. The vendor states that VIA MODEL CONTEXT PROTOCOL, AIGENSEI CONNECTS TO ANY LIVE DATA SOURCE, naming CRMs, knowledge bases, ticketing systems, PRICING ENGINES and ERP SYSTEMS. Those are genuinely different classes, and pricing engines and ERP are the two that suggest real enterprise deployments rather than a starter set. BUILDING ON MCP RATHER THAN ON CONNECTORS means coverage is bounded by what a customer's systems expose through the protocol rather than by the vendor's integration roadmap. For a small company selling into regulated enterprises, that is the only way to claim breadth credibly, and it is why the absence of a numbered connector count is not a weakness here. TOOL CALLING IS A NAMED ARCHITECTURAL STAGE rather than an implied capability: step four states that WORKFLOWS INVOKE ANY TOOL, RAG KNOWLEDGE BASES, MCP SERVERS CONNECTED TO LIVE SYSTEMS, OR EXTERNAL AGENTS. Invoking external agents as a tool class is worth carrying, since it means another vendor's agent can be a step inside an Aigensei process. THE LIVE-DATA INSISTENCE IS REPEATED THREE TIMES, ACTS ON REAL DATA, NOT CACHED ANSWERS, which is a claim about read freshness rather than integration breadth but does indicate the connections are queried at execution time. CONFIDENCE IS MEDIUM AND THE LIMIT IS SPECIFIC: no individual integration is named, no catalogue or count exists, and no connector configuration is documented. Class breadth rests on the five system types listed. A partner platform list corroborates real deployments into a CMS, a support platform and a behavioural health product.

Stands at F and is the strongest cell on the record, because the architecture is published as seven named stages rather than asserted as orchestration. THE STAGES ARE SPECIFIC: request intake; a PLANNER AGENT that interprets intent and designs the execution path, determining which workflows apply, what information is needed and how to sequence the steps; workflow orchestration where PRE-CONFIGURED WORKFLOWS TAKE CONTROL with steps, CONDITIONAL LOGIC AND DECISION BRANCHES; tool calls; shared memory; a WRITER AGENT that formats output in the correct tone and brand voice; and a closed loop delivering a response or downstream action. CONTROL-FLOW VOCABULARY IS PRESENT, which most Full cells in this lane lack. Conditional logic and decision branches are named explicitly rather than implied by a canvas, and the planner-then-workflow split is the architecture worth carrying: the model decides which path applies, and a deterministic pre-configured workflow executes it. Reasoning selects, deterministic logic runs. For regulated processes that is the right division, and it is the same shape credited on outsystems and sema4-ai. MULTI-AGENT IS GENUINE BUT NARROW. Three specialised roles are named, planner, workflow executor and writer, each with a distinct job. That is division of labour rather than a general agent graph, and it is a deliberate design: the writer agent exists so output formatting cannot drift, which is a quality control rather than a capability. SCALE IS STATED AS A PROPERTY OF THE DESIGN: one configuration handles thousands of parallel process instances, which follows from instances being independent. What is not documented is looping, parallelism within a process, or failure and retry behaviour when a tool call fails mid-workflow.

Stands at F and is unusually well specified: four trigger classes are named in one sentence, covering the whole spread this axis asks for. STEP ONE OF THE ARCHITECTURE READS: ANY BUSINESS REQUEST, A FORM SUBMISSION, AN INBOUND MESSAGE, AN API TRIGGER, A SCHEDULED EVENT. THE PROCESS STARTS HERE. That is a channel class, a messaging class, an inbound programmatic class and the schedule class, stated as the platform's entry point rather than collected from scattered feature bullets. THE SCHEDULED EVENT IS THE ENTRY MOST RECORDS IN THIS LANE LACK. Across this session the schedule class has been the commonest gap, absent from kalcend, wassist, ai-library and play-fast among others. A platform positioning itself as infrastructure for end-to-end process execution needs recurrence, and it names it. THE INBOUND MESSAGE CLASS IS CORROBORATED by the embedded deployments: the platform runs live inside a partner's customer support product via a widget, so messages arrive from a real conversational surface rather than only in principle. PUTTING TRIGGERS AT STEP ONE OF A PUBLISHED ARCHITECTURE is a stronger form of evidence than a features list, because the vendor is describing how the system works rather than what it offers. A trigger that did not exist would leave a hole in a numbered sequence. One limit recorded: the API trigger is named here as an intake route and is credited on Ext as the platform's only outward-facing surface; it is the same fact serving two purposes legitimately, since how work arrives and whether the platform is callable are different questions about one endpoint. No webhook configuration, event subscription mechanism or scheduling vocabulary is documented.

Stands at F, though it is the least specified of the Full cells and the note should say so. RAG KNOWLEDGE BASES ARE NAMED AS A FIRST-CLASS TOOL CLASS in step four of the architecture, alongside MCP servers and external agents, and again on the homepage. A knowledge base invoked as a tool is a maintained retrieval structure the customer builds and keeps, not context assembled per request, which is what the persistence line asks for. THE LIVE-DATA CLAIM IS THE DISTINCTIVE HALF and the vendor repeats it three times: ACTS ON REAL DATA, NOT CACHED ANSWERS, and INFORMATION THAT WAS TRUE YESTERDAY is named as the failure mode being avoided. Grounding here is therefore two-sided: a persistent RAG corpus for documented knowledge, and live queries through MCP into CRMs, ticketing systems, pricing engines and ERP for current state. For the processes this platform runs, lead qualification and customer service resolution, both halves are necessary, since a policy lives in a document and an account balance does not. THE ARCHITECTURE PUTS RETRIEVAL AT A SPECIFIC STAGE, after planning and before synthesis, so the planner determines WHAT INFORMATION IS NEEDED and the workflow retrieves it. Retrieval driven by an explicit plan rather than by similarity to the last message is a more controlled shape. CONFIDENCE IS MEDIUM AND THE GAP IS THE MECHANISM. Nothing documents how a knowledge base is created, what formats are ingested, how it is indexed or refreshed, whether answers carry citations, or whether the customer or the vendor maintains it. The word RAG is doing all the work, and I read every page the navigation and footer expose. The shared memory layer is session state and is graded on Mem, deliberately not counted here.

F>P, and the vendor's own heading and body text disagree, which is what settles it. THE HEADING SAYS PERSISTENT MEMORY ACROSS STEPS. The body underneath says SHARED MEMORY ACROSS ALL WORKFLOW STEPS GIVES EACH AGENT FULL CONTEXT OF THE SESSION. Step five of the execution architecture says the same: results, retrieved data and decisions are stored in a shared memory layer so EVERY SUBSEQUENT STEP HAS FULL SITUATIONAL AWARENESS OF WHAT CAME BEFORE. ACROSS STEPS IS NOT ACROSS SESSIONS. Every description scopes the memory to one run of one process: within the seven-step loop, between the planner, the workflows, the tool calls and the writer agent. The ruling places state that lives only within a session at Partial, and this is that, described three times consistently. THE ARCHITECTURE CONFIRMS THE SCOPE rather than contradicting it. Step seven closes the loop and delivers the response; nothing describes what survives afterwards, and the platform's own framing is that ONE CONFIGURATION HANDLES THOUSANDS OF PARALLEL PROCESS INSTANCES, which is a design where instances are independent and disposable. ONE COUNTERVAILING CLAIM RECORDED AND NOT CREDITED. A separate capability bullet reads CONTINUOUS IMPROVEMENT: LEARNS FROM OUTCOMES OVER TIME. GETS BETTER AS IT OPERATES, WITHOUT MANUAL RETRAINING OR ENGINEERING EFFORT. That is accumulation language and would be a route to Full under the ruling if a mechanism existed. None is described: no store, no retention, no per-customer or per-entity memory, and no statement of what is retained or how it is applied. A one-line claim of learning with no artefact behind it is thought-leadership prose, and this is the third record this session where a learning claim sat separately from the memory mechanism. WHAT WOULD MOVE THIS is any documented state surviving a closed loop, which for a platform running lead qualification and customer service would be the obvious next capability.

F>P. What is documented is escalation, and escalation is an exit rather than a checkpoint. THE MECHANISM IS REAL AND BETTER THAN MOST: SET ESCALATION THRESHOLDS BY WORKFLOW, SEGMENT, OR RISK. AI HANDS OFF AT THE RIGHT MOMENT WITH FULL CONTEXT, SO HUMANS NEVER HAVE TO ASK WHAT HAPPENED. Configurable thresholds keyed to risk are a genuine oversight instrument, and handing off with the full execution context attached is the property that separates a usable handoff from a dropped ticket. A second passage adds that every process runs WITHIN THE BOUNDARIES YOUR ORGANIZATION DEFINES, and that the platform knows WHEN TO BRING A HUMAN IN. WHY THAT IS PARTIAL AND NOT FULL, and the distinction is the one this axis turns on. Escalation transfers the work to a person when the agent judges it should not proceed. An approval gate stops the agent before a specific action and waits for permission to take it. Nothing documented pauses execution pending a human decision, and no checkpoint, pending-action queue or reviewer approval surface appears anywhere on the site. THE COMPARISON WITHIN THIS BATCH MAKES THE LINE VISIBLE. agentx reached Full on HUMAN-IN-THE-LOOP CHECKPOINTS AT ANY STEP, a gate placed into the flow. wassist held at Partial on escalation alone. outsystems reached Full on a Human activity that pauses the workflow until a person approves or rejects. Aigensei is in the wassist position with better configuration around it. ONE THING WORTH FLAGGING FOR A BUYER: this platform executes end to end in healthcare, financial services and insurance, and its own architecture closes the loop with a downstream action. Whether a human can require sign-off before that action is exactly the question a regulated buyer asks, and the site answers only that the agent will escalate when it decides to. An Operations and Approvals playbook is published, which suggests approval flows are something customers build rather than a platform primitive.

F>P on the vendor's own word, and this is the third instance of the same hedge in two days. SOC 2-ALIGNED INFRASTRUCTURE is stated twice on the platform page and once on the homepage, and aligned is a named Partial rung in section 7's hedge ladder. It says the infrastructure was built against the standard's control objectives; it does not say an auditor examined it or that a report exists. No type, no period, no audit firm, no trust page and no report request path appears anywhere on the site, whose full navigation and footer I read. THE CONTROL HALF IS GENUINELY MET AND IS WHY THIS IS PARTIAL RATHER THAN LOWER. Role-based access controls with GRANULAR PERMISSIONS AT EVERY LEVEL OF THE ORGANIZATION, data residency controls, and full audit trails are each named with a description. That is a real control surface for a company at this stage. THE LADDER NOW HAS THREE RECORDS ON IT FROM THIS BATCH, which is a useful calibration set: joget states ISO 27001:2022 CERTIFIED and reaches Full; altilia states a management system ALIGNED WITH ISO 27001 and sits here; aigensei states SOC 2-ALIGNED and sits here too. The word is the whole difference and each was read literally. WORTH RECORDING FOR THE READER: the vendor's positioning makes this gap more visible, not less. The page opens with SECURITY AND COMPLIANCE AREN'T FEATURES WE ADDED, THEY'RE CONSTRAINTS WE DESIGNED AROUND and targets healthcare, financial services and insurance. A buyer in those industries asks for the report, and aligned is the answer that ends the conversation. Data residency is credited here as a governance control rather than on Dep, where the deployment surface is graded separately; the two are kept apart deliberately.

Stands at F, and it clears the reporting-versus-auditing line explicitly rather than by inference, which is rare on this axis. THE DECISIVE CLAUSE IS NOT JUST OUTCOMES, BUT THE FULL DECISION CHAIN. That phrase is the axis definition: seeing what happened is reporting, reconstructing why is auditing, and the vendor names the distinction itself and claims the second. A second passage adds EVERY ACTION, DECISION, AND BRANCH IS LOGGED, TRACEABLE, AND EXPLAINABLE. NO BLACK BOXES. NO GAPS IN THE RECORD. BRANCH-LEVEL LOGGING IS THE DETAIL WORTH CARRYING and it ties directly to the orchestration credited on Orch. In a system whose workflows carry conditional logic and decision branches, recording which branch was taken is what lets an auditor reconstruct the path rather than infer it from the outcome. Most platforms in this lane log actions; logging the branch is a step further. THE COMPLIANCE FRAMING IS OPERATIONAL RATHER THAN DECORATIVE: WHEN YOUR COMPLIANCE TEAM ASKS WHAT THE AI DID, AND WHY, YOU'LL HAVE THE ANSWER. And the architecture's stated purpose is a closed loop WITH EVERY DECISION LOGGED, EVERY ACTION TRACEABLE, AND EVERY ESCALATION PRECISE, so auditability is described as the design goal rather than a feature bolted on. EXPLAINABILITY IS CLAIMED AS A SEPARATE PROPERTY from logging, which is the right split: a log says what happened, explainability says why the planner chose that path. What is not documented is the artefact itself: no example record, field list, retention period, export path, dashboard or query surface appears anywhere on the site. The claim is unusually precise and entirely unillustrated, which is the honest limit on a Full grade and the first thing to verify if this cell is cited.

Stands at P, re-based, and the deployment position is narrower than the record's SaaS-plus-embedded framing suggested. WHAT IS DOCUMENTED IS DATA RESIDENCY CONTROLS, YOUR DATA STAYS WHERE YOU NEED IT, named alongside RBAC and audit trails in the security section. Residency control stated as a customer choice is the residency half of this axis and it is more than the fixed-region disclosure that cost outsystems its first basis. It is also the right control for the stated market, healthcare, financial services and insurance. THE EMBEDDED ROUTE IS THE SECOND HALF AND IS UNUSUAL. The platform runs inside partner products, named as a CMS, a customer support platform and a behavioural health product, with one described as running live VIA THE AIGENSEI WIDGET. Running inside somebody else's product is a real deployment surface and it is not the same as SaaS, though it is the partner's infrastructure rather than the customer's. WHY IT HOLDS AT PARTIAL. Nothing documents the customer controlling where the software runs: no self-hosting, no private cloud, no VPC deployment, no on-premises option and no region list appears anywhere on the site, whose full navigation and footer I read. Data residency controls tell a buyer their data can be pinned; they do not tell them the platform can run inside their perimeter. THE CONTRAST WITHIN THIS SESSION IS INSTRUCTIVE and worth carrying. play-fast reached Full on DEPLOY IN YOUR OWN VPC with a described mechanism and a marketplace purchase route. ren3 holds Full on fully air-gapped deployment with zero external dependencies. Aigensei targets the same regulated buyers with residency controls only, which for a healthcare or insurance procurement team is a materially weaker answer. The SOC 2-aligned claim and RBAC are governance and are graded on Sec; residency is graded here. The two are deliberately kept apart.

Stands at P, and the site's footer supplies evidence the July basis did not have, in both directions. SIX PLAYBOOKS ARE PUBLISHED AS INDIVIDUALLY ADDRESSABLE PAGES: Sale Qualification, Customer Service Resolution, Onboarding and Intake, Operations and Approvals, HR and People Operations, and Finance and Compliance. Playbooks are a top-level navigation section. That is catalogue-shaped, which is the evidence form the 31 August bar names, and it is more than a use-case list because each has its own URL. WHAT HOLDS IT AT PARTIAL IS THE VENDOR'S OWN POSITIONING, stated three times and central to the pitch: AIGENSEI DOESN'T PRESCRIBE A WORKFLOW. YOU CONFIGURE YOUR PLAYBOOK, and CONFIGURABLE, NOT PRESCRIBED. EVERY WORKFLOW IS CONFIGURED TO YOUR STEPS, YOUR LOGIC, YOUR DECISION CRITERIA, NOT A GENERIC TEMPLATE. A company that markets itself on not shipping templates is telling you the playbook pages are process families it runs rather than assets you adopt. THAT TENSION IS THE FINDING, and it is genuinely unresolved rather than a hedge: either the six pages are adoptable starting configurations, which would carry Full, or they are worked examples of processes the vendor will configure for you, which is Partial. I did not read a playbook page and cannot tell from the navigation alone. Reading one settles it, and it is the single cheapest check on this record. THE ENGAGEMENT SHAPE POINTS TOWARD PARTIAL. The demo call to action asks prospects to TELL US YOUR HIGHEST-PRIORITY PLAYBOOK so the vendor can walk through how Aigensei would run it, which describes configuration performed with the customer rather than a template they install. Under the 31 August ruling, capability supplied by the vendor's people is not platform capability. Pre-configured workflows are the customer's own once built, and are credited on Orch.

Stands at N. No model provider is named anywhere on the site and no selection mechanism of any kind is documented. THE ABSENCE IS COMPLETE ACROSS EVERY PAGE THE NAVIGATION AND FOOTER EXPOSE: no provider, no picker, no bring-your-own-key, no endpoint configuration, no per-workflow model setting and no routing. The seven-step architecture names a planner agent and a writer agent without saying what powers either. THIS IS THE WEAKER FORM OF ABSENCE AND THE NOTE SHOULD SAY SO. Per the ground rules a vendor naming a single provider is the best-evidenced absence, because a buyer at least learns what runs their process. Here nothing is disclosed, so a customer in healthcare or insurance cannot tell which model reads their patient or claims data, or where inference happens. Against a record that positions on defensibility, explainability and audit trails, non-disclosure of the model is a conspicuous omission rather than a neutral one, and it sits oddly beside data residency controls: knowing where data rests matters less if you do not know who processes it. CONFIDENCE IS MEDIUM RATHER THAN HIGH. The site is a Framer marketing build with no documentation layer, so the absence is observed against a thin surface rather than against a component reference of the kind that made the joget and pickaxe negatives strong. A model configuration option could plausibly exist in-product without appearing on a five-page marketing site. ONE ADJACENT FACT RECORDED AND NOT CREDITED: the platform invokes external agents as a tool class, which lets a customer route work to an agent they control and whose model they chose. That is extensibility of the action surface rather than choice of the model powering Aigensei's own planner and writer agents, and crediting it here would be one fact working two axes.

F>P, and the July basis is the clearest one-fact-wrong-axis case in this batch: all three facts it cited belong somewhere else. MCP SERVER INTEGRATION points inward. The vendor states that VIA MODEL CONTEXT PROTOCOL, AIGENSEI CONNECTS TO ANY LIVE DATA SOURCE, so Aigensei is the client calling out to CRMs, knowledge bases, ticketing systems, pricing engines and ERPs. Under the standing one-line test that is integration, and it now sits on Int alone. The same correction was applied to wassist, agentx and joget this session. THE ABILITY TO INVOKE EXTERNAL AGENTS points inward too, for the same reason: Aigensei calls them. API TRIGGERS ARE THE ONE FACT THAT POINTS THE RIGHT WAY, and it is why this lands at Partial rather than None. Step one of the execution architecture lists AN API TRIGGER among the ways a request enters, so an external system can start an Aigensei process programmatically. That is genuinely the platform being callable from outside. WHY IT DOES NOT REACH FULL. Mike's 30 August bar asks for a DOCUMENTED API or SDK. An API trigger named in a list of four intake types is a capability mentioned, not a surface published: no endpoint, no authentication method, no reference, no SDK and no developer documentation exists. I read the full navigation and footer, and the site's sections are Platform, Playbooks, Partners, Resources with Blog and News, Company, Privacy and Terms. There is no developer entry anywhere. THE EMBEDDING ROUTE IS RECORDED AND NOT CREDITED: the platform is embedded into partner products including a CMS and a customer support platform, which implies an integration surface exists, but a partner integration performed commercially is not a documented developer API. This is the cell to revisit if a developer portal appears; on the current site there is nothing to read.

Stands at N under the 31 August Eval bar, and one adjacent claim is refused explicitly. NO TESTING SURFACE OF ANY KIND IS DOCUMENTED: no preview, sandbox, simulation, test run, scoring, test set, expected outputs, version comparison or debugging view appears on any page the navigation and footer expose. The build path described is configuring a playbook and having the platform run it. THE CLAIM THAT LOOKS LIKE EVAL AND IS NOT: CONTINUOUS IMPROVEMENT. LEARNS FROM OUTCOMES OVER TIME. GETS BETTER AS IT OPERATES, WITHOUT MANUAL RETRAINING OR ENGINEERING EFFORT. That is the platform improving itself, with no artefact the customer reads and no comparison they can run. The ruled bar asks for a result the CUSTOMER can read and compare about the agent's behaviour on their own work, and an internal feedback loop is the opposite: it changes behaviour without telling anyone what changed. THE AUDIT TRAIL CREDITED ON OBS IS ALSO NOT AN EVAL SURFACE. Recording every action, decision and branch tells an operator what happened in a given run; nothing scores whether it was right, replays a case, or compares one configuration against another. THE COMBINATION IS THE PART WORTH FLAGGING FOR A BUYER, and it is sharper here than the grade alone conveys. This platform executes end to end in healthcare, financial services and insurance, claims to learn and change over time, and offers no way for the customer to verify that a change was an improvement. A compliance team can reconstruct what the AI did on Tuesday and cannot establish whether Tuesday's version behaved better than Monday's. For a product whose entire pitch is defensibility, that is the gap I would raise first. Confidence medium; the site is a marketing build with no documentation layer, so an in-product test affordance would not necessarily appear here.

Stands at N, and confidence rises to high because the platform's action surface is now fully enumerated rather than merely unexamined. STEP FOUR OF THE PUBLISHED ARCHITECTURE CLOSES THE SET: workflows invoke ANY TOOL: RAG KNOWLEDGE BASES, MODEL CONTEXT PROTOCOL SERVERS CONNECTED TO LIVE SYSTEMS, OR EXTERNAL AGENTS. Three tool classes, all programmatic. When a vendor publishes the complete list of what its workflows can invoke, absence of a browser from that list is evidence rather than a gap in my reading. THE ARCHITECTURE MAKES IT STRUCTURAL. MCP is a protocol for calling systems through defined interfaces, and the vendor's stated advantage is acting on live data through it rather than working around systems that lack access. A platform whose whole premise is protocol-mediated integration has no reason to drive a screen, and driving one would break the auditability it sells: a logged MCP call is reconstructible in a way a sequence of clicks is not. NO NEAR-MISS EXISTS ON THIS RECORD, which is worth stating given how many I have refused this session. There is no scraping utility, no code execution, no sandbox, no screenshot capability and no web-access tool named anywhere. The one place a false positive could arise is the widget embedded in a partner's support platform, but that is Aigensei being embedded in someone else's interface, which is the reverse of operating one. Everything else the platform touches, form submissions, inbound messages, API triggers, scheduled events, CRMs, ticketing systems, pricing engines and ERP, is reached through documented programmatic paths.