Enhans

No third party system is named by product anywhere on the site. Two full platform pages, a product navigation of five modules, seven agent pages and four worked use cases name no ERP, CRM or marketplace, and no data warehouse or collaboration tool. The closest is a category list, "bring databases, APIs, and files into AgentOS," plus industry names rather than system names, so a buyer cannot tell whether it connects to their stack.

Agents do take authenticated action in outside systems, but they do it through ACT-2 operating browsers, SaaS platforms and admin panels, along with operational portals. What remains is a short, unnamed list of sources coming in. Pipeline Builder "connects and prepares enterprise data," bringing databases, APIs and files in so data is ready for execution, and App Builder sends results to dashboards and views inside the platform.

Ingesting from a customer's databases is reading from them, and delivering to the platform's own views does not reach an outside system. There is no named integration catalog and no documented support for custom tools: Agent Builder "connects them with tools, rules, and conditions" without naming a tool, saying how one is added or publishing a tool interface.

This follows from the design. Enhans answers integration by driving interfaces rather than publishing connectors, because "many enterprise systems do not expose complete APIs." Pipeline Builder has its own page, which may hold a connector list.

Sourceenhans.ai/agent-os Pipeline Builder and Agent Builder sections, enhans.ai/act-2 API-limited system coverageread 2026-09-14

AgentOS runs work in several steps across several agents. The steps form a named, ordered architecture of five modules on one execution path: Pipeline Builder prepares data and Ontology Manager defines business meaning and relationships; Agent Builder designs agents and execution flows and App Builder connects business meanings to operational interfaces; and ACT-2 carries out the business work. The vendor states the sequence as the architecture: "AgentOS connects enterprise data, ontology, agents, workflows, views, and action in one execution architecture... making each layer explicit."

Running several agents together is named as a differentiator: AgentOS "enables multi-agent systems to operate according to enterprise logic" and "allows enterprises to build and connect agents for specific business purposes so they can run within real workflows and operating logic." In the market monitoring use case, monitoring agents run over Pipeline Builder, ontology management and workflow logic, with Price Agent, Social Media Agent and Brand Protection Agent as the example agents on one flow.

The customer composes the flows. Agent Builder lets a customer "build task-specific agents on top of enterprise data and ontology, then connect them with tools, rules, and conditions to create workflows that can be applied in real operations," and the FAQ adds that the customer defines how agents operate and what information they can use, when actions fire and how exceptions are handled. Rules and conditions written per flow are branching the buyer controls.

No named runtime, BPMN or graph notation, or versioning is published, nor any retry or concurrency behavior, and nothing says what happens when a step fails in a flow with several agents.

Sourceenhans.ai/agent-os architecture layers, differentiators and use cases, FAQ Q5read 2026-09-14

The retrieval structure is a named product module, and it is a graph. Ontology Manager "turns data into business meaning," with the aim to "define entities, relationships, rules, and terminology so AI can work with real enterprise context." Entities and relationships with rules over them form a semantic layer that can be queried, rather than context assembled for each run.

Persistence is stated outright. AgentOS "builds a separate ontology lake while keeping existing systems in place: instead of modifying enterprise databases directly, AgentOS uses Pipeline Builder to store the required data separately and organize it in a way AI can use." A separate stored layer, built by an ingestion module from databases, APIs and files and queried by agents at run time, scales past a context window because it is a store rather than a prompt.

The FAQ makes the grounding case itself: "ontology gives AI the structure it needs to work with enterprise context... without ontology, AI may generate plausible responses, but it is far harder to make those responses consistent, explainable, and operationally useful." The structure is maintained, not built once: the vendor says Ontology Manager generates about ninety percent of the ontology automatically from source system data, with the rest completed by forward deployed engineers on site.

The ontology describes the customer's business, not state an agent keeps about its own work. No retrieval mechanism or query interface is disclosed, and no embedding approach or citation surface, so how agents query the ontology, and what provenance an answer carries, is not published.

Sourceenhans.ai/agent-os Ontology Manager, ontology lake and FAQ Q3read 2026-09-14

Decisions are reserved for the customer, and there is a surface for setting constraints, but no review and approve step is documented. Reserving decisions is stated as a product property throughout, and Agent Builder lets the customer bound agent autonomy: "it makes it possible to define how agents should operate, what information they can use, when actions should be triggered, and how exceptions should be handled."

Defining exception handling at build time is a bound on autonomy that the customer controls. ACT-2 adds a claim of bounded execution: "AI agents can take action without giving up control over the execution environment," through a "governed execution layer." The tagline "you decide and our agents act" is positioning.

No approval queue, pending state or accept and reject action is named, and no reviewer, risk threshold per action or escalation path to a named person, nor any record of who approved what.

"How exceptions should be handled" does not say the handler is a person, and on a platform built for unattended repetition it could be another agent: ACT-2's Adapt step describes "fallback execution" with no human in it.

The execution layer is sold on reducing human involvement, to "reduce the need to re-reason through the same workflow on every run" so that "high-volume automation becomes more economically viable." The Agent Builder module page may specify a validation step.

Sourceenhans.ai/agent-os Agent Builder FAQ, enhans.ai/act-2 governed execution and adapt stepread 2026-09-14

No security attestation or access model is published. The site offers phrasing conditional on deployment, "it can be deployed to match customer infrastructure and security requirements" and "enterprise AI must account for existing systems, security and infrastructure requirements," which describes accommodating what the buyer already has and says nothing about what Enhans itself does.

No SOC 2, ISO 27001, auditor, report or trust center appears, nor a compliance page, and no SSO, SAML or SCIM, nor RBAC, roles or a permissions model. The navigation is large and can be listed in full, from AgentOS with its five modules to Insights and Company, and it carries no security, trust or compliance entry at any level. The only legal link in the footer is a privacy policy.

Customer logos are not a security control and a marketplace listing is a way to buy: adoption by large enterprises and defense buyers is a commercial fact, not a security posture. On premises and private cloud deployment and ACT-2's execution records are separate matters.

Two first party surfaces could carry security material: the Insights > Documents section, the natural home for a security whitepaper, and the vendor's Azure Marketplace listing. A vendor selling into defense may hold an attestation, though nothing published says so.

Sourceenhans.ai/agent-os deployment section and full navigation, enhans.ai/act-2 navigation and footerread 2026-09-14

Each ACT-2 run returns a set of evidence. Among its core capabilities is "execution evidence," to "return results, screenshots, change records, and request-level artifacts," so that "teams can audit what happened and connect execution back to the original decision." Four kinds of artifact come back per run, tying an action back to the decision that caused it.

What is recorded is the agent's own execution, at the level of each request, not the health of the customer's operations, and it supports reconstruction rather than reporting: screenshots and change records show what the agent saw and what it changed, and linking execution back to the decision is a causal chain rather than a metric. For a product that operates interfaces rather than APIs this is the harder case, since there is no system log to inherit, and the artifacts come from Enhans's execution layer, not from the systems being operated.

Enhans treats it as a differentiator. The comparison table sets "limited verification" against "evidence and execution records," the page describes enterprise automation as "entering the required system, following the right process, completing the action, and proving the result," and "teams need traceable records of what was executed" is listed among the reasons generic computer use does not scale.

No retention period or export path is published, and no admin view across users or agents, or alerting, and nothing says where these records are stored or for how long.

Sourceenhans.ai/act-2 execution evidence, comparison table and enterprise-execution framingread 2026-09-14

Agent memory is not documented: nothing names a store, scope or lifetime, or a retention period or purge path. A buyer cannot say where agent memory lives or delete it for one customer without touching the ontology lake, which is the application's data model, and no store of facts that users maintain and the agent consults is documented either.

The persistent ontology describes the customer's business, its entities and relationships, rules and terminology, held in a separate ontology lake; it is not state an agent writes about its own work and reads back. Learning continuously across cycles is learning absorbed into the product, not a documented store with a scope and a lifetime.

The closest candidate is ACT-2's Reuse step: "successful action paths can be saved and applied to similar future tasks," and among its capabilities "reusable workflow execution," described as "convert successful task paths into workflows that can be used again" to "reduce the need to re-reason through the same workflow on every run."

That is the agent writing something lasting from its own experience, but it becomes a workflow; the vendor's verb is convert, and the path is promoted into a procedure the platform replays. Procedures and workflows are instructions the product applies, not context the agent reads in order to decide.

The Agent Builder and Ontology Manager pages may describe a state object for agents, though nothing on the platform pages claims one.

Sourceenhans.ai/act-2 reuse step and reusable workflow execution, enhans.ai/agent-os ontology layerread 2026-09-14

Two customer environments are named, on premises and private cloud, on two separate product pages. The AgentOS deployment section says "it can be deployed to match customer infrastructure and security requirements, including on-premise and private cloud environments." These are the customer's environments rather than vendor regions: the software runs where the buyer is.

The execution layer repeats it, so the part that touches the customer's systems can run in the customer's own infrastructure: "ACT-2 can also be deployed in controlled environments, including on-premise or customer-managed infrastructure, where execution control and system access matter." Its comparison table sets "flexible deployment, including customer-managed and on-premise environments" against "cloud-hosted execution by default" as what it does differently.

The design fits the claim. AgentOS "builds a separate ontology lake while keeping existing systems in place," storing the data it needs separately instead of changing enterprise databases, and the stated fit is "no rip-and-replace." A product that sets up its own data layer beside a customer's systems can set it up inside their estate. Two concrete environment types are named on two pages, and one is positioned as a differentiator against hosted alternatives.

No region list, residency commitment or data location statement for the default cloud is published, and no installation or architecture documentation describes what an on premises deployment involves. The choice is published but its mechanics are not, and with quotation based delivery the boundary is negotiated rather than specified.

Sourceenhans.ai/agent-os built for enterprise deployment section, enhans.ai/act-2 deployment comparisonread 2026-09-14

A named set of prebuilt agents ships under CommerceOS, even though the AgentOS page says it is not one. The AgentOS page states "AgentOS is not a catalog of pre-built agents. It is the platform where enterprises connect their data, define business meaning, build task-specific agents...", its FAQ says pre-built agents serve narrow predefined tasks while AgentOS gives enterprises the tools to build their own, and its four worked scenarios are labeled "representative scenarios, not fixed product packages." That disclaimer is about the build platform.

The named set sits one level up in the navigation. The AI Agent menu carries CommerceOS and, under "Specialized AI agents," seven agents with their own pages and durable URLs: Price Agent, Promotion Agent, SNS Agent, QA Agent, Brand Protection Agent, Product Experience Agent and AD Agent. Each is a whole product: remove the AD Agent and the Price Agent still does its job, and pricing, advertising and brand protection, like social posting, quality assurance and review analysis, are separate commercial functions.

They are units a buyer adopts. The market monitoring scenario names Price Agent, Social Media Agent and Brand Protection Agent as the "example agents," and industry pages pair single agents with single verticals: Ecommerce with QA Agent, Fashion with SNS Agent and F&B with Brand Protection Agent. AgentOS is sold as a build platform and CommerceOS as a packaged set.

No entitlement, install or enable action is published, and no pricing per agent exists.

Sourceenhans.ai/agent-os not-a-catalog statement and use cases, enhans.ai/act-2 navigation CommerceOS specialized agent listread 2026-09-14

Trigger conditions can be configured, a real but thin seam. The Agent Builder FAQ says a customer can define "when actions should be triggered," alongside how agents operate, what information they can use and how exceptions are handled. Trigger conditions written per agent make the platform event driven in substance rather than run by hand.

A second, narrower mechanism appears in a worked use case: "monitor market signals in real time and connect insights to operational response," built with Pipeline Builder, ontology management and "monitoring agents," along with workflow logic and dashboard views. Continuous monitoring that fires a response is an event pipeline, and monitoring agents are named as a class of actor.

What is published is that triggers can be configured, not what can fire one. No event source is named: no webhook, schedule or inbound API call, no message queue or subscription to a system's change events, and no mailbox, chat channel or ticket queue. Output surfaces ("outputs can be delivered through dashboards, generated views, and natural-language interfaces") are breadth of delivery, not event coverage. The Agent Builder and Pipeline Builder pages may list a scheduler or event sources.

Sourceenhans.ai/agent-os Agent Builder FAQ and market monitoring use caseread 2026-09-14

ACT-2, Enhans's own computer use model, runs the actions, and the customer cannot choose or route models. No model selector, admin entitlement or model setting per agent or workflow appears on either platform page or in the product navigation, and no disclosed routing or bring your own key or model path. Agent Builder lets a customer choose agents and tools, rules and conditions; the model is not among them.

ACT-2 is the platform's headline technical asset, with its own product page and subdomain and a benchmark claim attached. A vendor that trained the action model has a coherent reason to fix the stack, but the customer still gets no choice.

Disclosure is partial. Enhans names its own model, but no provider, family or version is named for any other part of the platform: the reasoning, planning and language layers across Agent Builder, App Builder and the ontology work are not attributed, and the site has no subprocessor list. A buyer can learn what drives their screens but not what reads their ontology.

The vendor reports ACT-2 ranking in the global top five on Online-Mind2Web alongside Google, OpenAI and Anthropic. That is a claim about model quality, and naming three frontier labs as benchmark peers does not make them available models.

Sourceenhans.ai/act-2 in-house model and benchmark claim, enhans.ai/agent-os Agent Builder configuration surfaceread 2026-09-14

No public API, SDK or developer surface for AgentOS appears on the site. The navigation, from the five AgentOS modules to Insights and Company, has no developers entry, API reference or SDK, and no documentation portal or docs subdomain. No agent card, webhook or CLI is mentioned, and the builders are authoring surfaces inside the product.

The documented interfaces point outward. Pipeline Builder brings "databases, APIs, and files into AgentOS," which is AgentOS consuming other systems' APIs, and ACT-2 driving external systems runs the same way. Neither lets an outside caller drive AgentOS.

The vendor's own Microsoft Marketplace listing summary mentions "MCP-based integration support" alongside the deployment options, without saying which way it runs: an MCP server would expose AgentOS to a customer's assistants, while an MCP client would only consume tool servers. No API or SDK for the platform is documented either way. The listing is a way to buy rather than a way to extend, the offering is quotation based, and the listing's full text or the Insights > Documents section may say which way MCP runs.

Sourceenhans.ai/agent-os and /act-2 navigation and Pipeline Builder, Microsoft Marketplace listing unreadread 2026-09-14

No way to test or evaluate the agents is documented. No evaluation harness, scored test cases or golden set is published, nor a judge, regression suite or A/B comparison between agent configurations, nor a release quality gate or a loop that measures the deployed agent against outcomes. No debugging surface is published either.

Simulation appears on the site, but of the customer's business rather than the agent: agents built on the ontology automate decision domains including cost analysis, audit and simulation. Simulating a pricing scenario or a cost structure evaluates the business, not whether the agent's work was correct.

The vendor reports that ACT-2 ranks in the global top five on the Online-Mind2Web computer use benchmark alongside Google, OpenAI and Anthropic. That measures the underlying action model, not agent behavior on a customer's work, and a vendor's own published benchmark is not something a buyer can run against their workflows.

ACT-2's execution evidence and its handling of processes with several steps, with "checks and confirmations," show what happened on a given run. They do not tell a buyer whether a change to an agent made it better. The Insights > Documents section or the Agent Builder page may publish accuracy measurement, though nothing on the platform pages claims any.

Sourceenhans.ai/act-2 execution evidence and comparison table, enhans.ai/agent-os use casesread 2026-09-14

Computer use has its own page, "The enterprise computer use for AgentOS," covering the browser and desktop applications. ACT-2 is "the AI execution layer that turns decisions into actions across browsers, business systems, and operational tools," connecting to "browsers, SaaS platforms, admin panels, internal tools, and operational portals", and the capability is stated directly: "operate browsers and business tools through a governed execution layer."

The agent navigates, and the vendor owns the environment. "The agent performs the workflow through a controlled computer-use environment," and Enhans runs it rather than wiring in another company's engine: ACT-2 is its own model, and the comparison table contrasts it with "hosted CUAs" built for individual task help.

The page takes on fragility directly, which marks real interface operation rather than an API integration described in interface terms: "business tools change screens, fields, and workflows over time," and "when a screen, field, or workflow changes, ACT-2 can support fallback execution and workflow updates." The stated reason is "API-limited system coverage," work "across tools and portals where APIs are incomplete, unavailable, or impractical," since "many enterprise systems do not expose complete APIs."

The execution cycle has four documented steps: Explore, where ACT-2 "maps the target system and identifies the actions needed," then Execute in the controlled environment, then Reuse and Adapt.

Sourceenhans.ai/act-2 computer use layer, core capabilities and execution cycleread 2026-09-14