Boomi vs SnapLogic (2026)

Stands at F and is the least contestable cell on the record. Breadth across classes is not in question: more than a thousand prebuilt Snaps spanning ERP, CRM, databases, data warehouses, SaaS applications and on-premises business software, which is a twenty-year integration catalogue rather than an agent-era connector programme. THE TOOL-CALLING HALF IS EXPLICIT AND WAS NOT CITED BEFORE. Tool Calling Snaps exist across the LLM Snap Packs, the OpenAI Responses API tool calling path is documented, and an OPENAPI FUNCTION GENERATOR SNAP turns an OpenAPI specification into callable functions. That last one matters more than its name suggests: any system with a published API spec becomes an agent tool without anyone hand-authoring a connector, which is how a catalogue this size stays current. THE GOVERNANCE ADDITION FROM 2026 IS WHAT DISTINGUISHES THIS FROM A LARGE CONNECTOR COUNT. Tool lifecycle management, versioning, metadata and lineage controls apply to the tools agents call. Knowing which version of which tool an agent invoked, and where that tool came from, is the question an enterprise asks after a connector count stops being interesting, and few vendors in this lane answer it. The architectural point worth carrying: because agents are pipelines and pipelines are made of Snaps, there is no separate agent-integration layer to fall behind the main one. Every integration the customer already owns is reachable by an agent by construction. Retrieval connectors are credited on Know and the outbound MCP surface on Ext; neither is counted again here.

Stands at F, re-based onto the documented execution model rather than the general claim that it orchestrates pipelines. PIPELINES ARE THE ORCHESTRATION PRIMITIVE and the documentation is specific: a customer orchestrates A DYNAMIC SEQUENCE OF PIPELINE RUNS to accomplish a complex task, then deploys it to production as a Task. Multi-agent coordination is documented separately, with workflows COORDINATING ACTIVITY ACROSS MULTIPLE AGENTS AND ENTERPRISE SYSTEMS SIMULTANEOUSLY. THE SHAPE HERE IS DIFFERENT FROM MOST OF THIS LANE AND WORTH CARRYING TO COMPARISON PAGES. Orchestration is not a purpose-built agent graph bolted onto a chat product; it is a mature engine that agents were added into. The control-flow vocabulary, branching, iteration, sub-pipeline invocation through the Pipeline Execute Snap, error views on every Snap, is inherited from twenty years of integration work rather than written for agents last year. For long-running multi-step business processes the difference is operational: this engine already handles retries, timeouts, resumable pipelines and suspended states. RESUMABLE PIPELINES AND SUSPENDED STATE are documented in the task notification settings and are the detail most agent-native platforms lack, since a process that can suspend and resume is what a genuinely long-running workflow requires. The agentic layer sits on top: AgentCreator combines dynamic iteration with real-time generative decision-making, so the model decides the path while the pipeline engine executes it deterministically. That is the same reasoning-over-deterministic-execution split credited on sema4-ai and maisa. Ultra Tasks add always-on continuous execution for pipelines designed to run indefinitely.

Stands at F and is now one of the better-evidenced Trig cells in the lane. The July basis asserted the right answer without naming a mechanism; the documentation names three task types and they map cleanly onto three separate classes. SCHEDULED TASKS cover the schedule class with unusual depth: one-time execution, intervals, and full cron with calendar dates, clock time, frequency, end dates and time zones. BLACKOUT DATES are the detail worth carrying, letting a customer suppress invocation across planned outages or holidays. That is an operations feature rather than a scheduling checkbox, and almost nothing else reviewed in this lane has it. TRIGGERED TASKS cover the inbound API class: a pipeline becomes a web API endpoint invoked over HTTP, with data passed in and returned, and the OPEN API SPECIFICATION SUPPORTED so the endpoints download in Swagger form. That makes an agent callable by anything that speaks HTTP. ULTRA TASKS cover the streaming and always-on class, with a FeedMaster node queueing incoming messages and a listener-consumer construct that continuously polls a messaging service such as a JMS consumer. Continuous consumption is a genuinely different class from polling on a schedule. The deployment path is documented too: a Triggered Task can be routed through an on-premises load balancer to a Groundplex node, so the inbound endpoint can live inside the customer's own network. Schedule, inbound API and continuous stream is the full spread. The channel side sits on top through the MCP Server, which lets external clients such as Claude discover and invoke pipelines, and that route is credited on Ext rather than counted twice.

Stands at F, and the basis is rewritten because the July version leaned on MCP support, which belongs on Ext, and on generic integration language. WHAT CARRIES IT IS A REAL RETRIEVAL STACK RATHER THAN A CLAIM ABOUT ENTERPRISE DATA. VECTOR DATABASE SNAP PACKS cover Pinecone, OpenSearch, MongoDB and Snowflake; utilities parse HTML, Markdown, PDF and unstructured content and handle EMBEDDING AND STORING DATA IN VECTOR DATABASES; and OpenAI and Azure OpenAI vector store management with file upload is documented as improving contextual awareness of future queries. THE PERSISTENCE LINE IS CLEARED PROPERLY. A customer's vector index built and maintained through these Snaps is a maintained retrieval structure that survives between runs, not context assembled per request. The Agent Retrieve and Generate Snap makes retrieval-augmented generation a named platform operation rather than a pattern the customer invents. THE DISTINCTIVE PROPERTY FOR THIS LANE is that grounding reaches operational systems rather than only documents. Because the retrieval layer sits on the same fabric as a thousand-plus connectors to ERP, CRM, databases and warehouses, an agent can ground on a live record in a system of record as readily as on a PDF. Most vendors here can do one or the other. Document handling is covered end to end, with the IDP Agent supplying prebuilt patterns for invoice and purchase order processing over unstructured input. One limit recorded: chunking strategy, re-indexing and freshness of the vector store are the customer's to manage, since the index is theirs rather than a vendor-run knowledge base. That is a genuine trade rather than a gap for an integration platform.

Stands at P, re-judged against the state half of the axis under the 31 August ruling. The July basis said a memory that PERSISTS AND LEARNS PER USER OVER TIME is not documented, which imported learning as a requirement. Accumulation is one route to Full and never the only one, so the cell needed re-deciding on state alone. It still lands at Partial, now for a reason that survives the ruling. WHAT IS DOCUMENTED IS SESSION STATE, which the ruling places explicitly at Partial. A pipeline CAN HOLD THE ENTIRE CONVERSATIONAL HISTORY from system prompt through all user and assistant messages, which is a conversation buffer living inside a run. THE MORE INTERESTING FINDING IS WHOSE MECHANISM THE PERSISTENT PART IS. The vendor writes that instead of managing conversation state yourself, YOU ALLOW ANOTHER SYSTEM TO MANAGE IT AUTOMATICALLY, and that its OpenAI and Azure OpenAI support extends to managing VECTOR STORES AND FILE UPLOADING to improve contextual awareness of future queries. The durable cross-request state there belongs to the model provider's own conversation and vector store management, not to a SnapLogic memory object. Under the standing question of whose mechanism it is, that is OpenAI's store reached through a Snap, the same shape as the is_consequential refusal on sema4-ai. No SnapLogic-native memory Snap, agent memory store, session identity object or retention configuration appears anywhere across two passes. WORTH SAYING PLAINLY: this is coherent for what SnapLogic is. An integration platform's answer to durable state is the customer's own database or vector store reached through a connector, and a customer can absolutely build persistence that way. But a general-purpose connector is not a documented memory primitive, and grading it as one would credit every iPaaS in the index with agent memory. The vector database Snap Packs are grounding and are credited on Know.

F>P. The July basis reads in full that agents are DESIGNED LOW CODE BY HUMANS and governed through enterprise AI governance. Neither half is a mechanism. A human building the agent is authorship, not oversight of its running behaviour, and an AI governance framework is exactly the governance essay section 7 says not to grade from. WHAT IS ACTUALLY SHIPPED, AND WHY IT IS PARTIAL RATHER THAN NONE. Two guardrails are documented as product features: AI RESPONSE VALIDATION in the AgentCreator governance set, and FINE-GRAINED ACCESS CONTROL over what an agent may reach. Response validation is a real constraint on agent output, so the guardrail half of this axis is genuinely met. WHAT IS ABSENT IS THE HUMAN HALF. Across two passes, including one anchored specifically on approval terms, no runtime approval step, checkpoint, pause-for-confirmation, task queue or reviewer surface appears in the AgentCreator documentation, the product pages, the data sheet or the 2026 release notes. Nothing documented stops an agent mid-run and waits for a person. ONE FEATURE THAT LOOKS LIKE OVERSIGHT AND IS ITS OPPOSITE, worth naming because it is easy to miscount: the July 2026 HANDLE ERRORS VIA AGENT toggle intercepts downstream tool failures and passes error details back to the LLM FOR SELF-CORRECTION. That is the agent recovering without a human, which is an autonomy feature. The vendor's own positioning points the same way. The AgentCreator page advertises resolving customer inquiries WITHOUT HUMAN INTERVENTION. This is a platform built for straight-through processing, and the grade should say so rather than credit governance language. This is the likeliest cell on the record to be understated if an approval Snap exists that neither pass surfaced. Agent Visualizer is inspection and is credited on Obs; access control is credited on Sec.

Stands at F, re-based, with two facts removed from the old basis and one important attribution corrected. REMOVED AS BELONGING ELSEWHERE. The July basis credited execution behind a firewall and geolocation and residency compliance, which are deployment properties graded on Dep, and TRUSTED BY REGULATED GLOBAL ENTERPRISES, which is customer-base inference rather than evidence. Reasoning from who buys a product to what controls it must have is the error corrected on mobagel in this lane. THE ATTRIBUTION CORRECTION MATTERS AND CUTS AGAINST THE VENDOR. Third-party listings state SnapLogic complies with SOC 2 AND ISO 27001. The vendor's own page is precise where the aggregators are not: SnapLogic itself holds SOC 1 Type 2, SOC 2 Type 2, SOC 3 and HIPAA-HITECH, and the ISO 27001, 27017 and 27018 certifications belong to AWS, whose posture it leverages. Under the ground rules a cloud provider's certifications are infrastructure, not the vendor's, so ISO is not credited here. This is a case where the vendor is more honest than the directories describing it. WHAT CARRIES THE GRADE IS STILL COMFORTABLY BOTH HALVES. Attestation: annually renewed third-party audits for SOC 2 Type 2, SSAE18 Type II and ISAE 3402 Type 2, plus SOC 1 Type 2, SOC 3 and HIPAA-HITECH, with audit summary letters available on request under NDA. Controls: single sign-on through SAML, integration with IAM and identity provider systems including Okta, Ping and OpenAM, role-based access controls, and per-asset permission tiers from read-only through owner. ONE ARCHITECTURAL PROPERTY WORTH CARRYING, since it is unusual and reduces exposure by construction rather than by policy: the vendor states it does not store customer data or pipeline content in the platform, only metadata, held inside the control plane with no outside service access. Certifications on request under NDA rather than through a self-serve trust portal is the one soft spot, but the hedge ladder in section 7 concerns unattested claims, and these are audited and named.

Stands at F, but the July basis had to be replaced entirely because what it cited was not observability. Platform monitoring of pipelines and PROCESSING TRILLIONS OF RECORDS MONTHLY is a scale statistic; volume says nothing about whether a customer can reconstruct what an agent did. WHAT ACTUALLY CLEARS THE LINE IS AGENT-LEVEL AND NAMED. The AGENT VISUALIZER provides what the vendor calls transparent, auditable insight into AGENT REASONING AND DECISIONS, and builders inspect REASONING STEPS, TOOL CALLS AND RESULTS. Reasoning steps and tool calls are the why rather than the what, which is the distinction this axis turns on. A second mechanism supports it and is architectural rather than a feature: because agents are pipelines, the pipeline CAN HOLD THE ENTIRE CONVERSATIONAL HISTORY from system prompt through every user and assistant message, and the vendor states this exists precisely to enable debugging individual operations at each runtime iteration. The execution record is the same object the agent runs on, so it cannot drift from what happened. The governance layer adds TOOL LIFECYCLE MANAGEMENT, VERSIONING, METADATA AND LINEAGE CONTROLS, which answers a question most vendors in this lane cannot: not just what the agent called, but which version of that tool, and where it came from. Underneath sits the SnapLogic Dashboard with pipeline execution monitoring, task run details and per-instance execution information. CONFIDENCE IS MEDIUM AND THE REASON IS SPECIFIC: the Agent Visualizer is described in design-time language, and I did not reach a page establishing whether the same reasoning trace is retained and queryable for production runs, nor any documentation of retention periods or export to an external observability stack. That is the check to run at lane close.

Stands at F, and it is the cleanest example on this record of a capability that is architectural rather than a deployment option bolted on. THE SNAPLEX SPLIT IS THE WHOLE ANSWER. The control plane runs in the vendor's cloud while the execution plane, the Snaplex, runs wherever the customer puts it: a GROUNDPLEX inside the customer's own network and firewall, a Cloudplex, or a mix. The documentation shows the consequence concretely rather than as a claim, with a Triggered Task routed through the customer's ON-PREMISES LOAD BALANCER to a Groundplex node, which contacts the control plane only for assets and can run from cache thereafter. WHAT MAKES THIS RESIDENCY RATHER THAN DISCLOSURE, the distinction that cost outsystems its first basis: the customer chooses where execution happens, and pipeline data never leaves that boundary. The vendor states it DOES NOT STORE CUSTOMER DATA OR PIPELINE CONTENT, only metadata in the control plane. So the residency question resolves to where the customer put the Snaplex, which is the strongest form this axis takes. For agents specifically this is the load-bearing property. An agent built in AgentCreator is a pipeline, so it executes on the same Snaplex, meaning agent execution and the enterprise data it touches can both sit inside the customer's own network while the design experience stays cloud-hosted. EMEA is separately documented as its own environment, so regional separation exists at the platform level as well. Per the standing ruling, none of this is credited again on Sec, where the attestations and access controls stand on their own.

Stands at F under the 31 August bar, but the basis needed rewriting because the July version rested it on THOUSANDS OF PREBUILT SNAPS. Snaps are connectors and are credited on Int; counting them here is one fact working two axes, and a connector is not a packaged agent. WHAT ACTUALLY QUALIFIES IS A BROWSABLE CATALOGUE, which is the evidence form the bar names. The SNAPLOGIC PUBLIC PATTERN LIBRARY contains AgentCreator pipeline patterns filterable by selecting AgentCreator and GenAI Builder as search criteria. A filter on a public library is as close to a literal browsable catalogue as this axis gets, and the documentation describes patterns as CANONICAL PIPELINE DESIGNS YOU CAN REPURPOSE EASILY IN YOUR ENVIRONMENT. The IDP AGENT is the strongest single item and the closest to a finished pack: automated document processing shipped with prebuilt patterns for named business tasks including invoice and purchase order handling. That is a working agent for a specific process rather than a scaffold. Around those sit prompt patterns through Prompt Composer with SnapGPT assistance, and the GenAI package's utilities bundled as a coherent starting set rather than assembled piecemeal. WORTH RECORDING AGAINST THE 30 AUGUST FINDING that only 32 percent of Full cells index-wide name a browsable catalogue: this record now names one explicitly, with the filter criteria documented, so it sits in the defensible third rather than among the majority asserting templates without a surface. What is not documented is a marketplace of finished agents by business role, of the kind mobagel's four pre-trained vertical agents represent. The patterns are designs to adopt rather than agents to switch on, which is the honest ceiling on this cell and the reason confidence is high but the record should not be cited as the strongest form of this axis.

Stands at F, and the basis is rewritten because the July version rested the grade partly on MCP support, which is the wrong axis. An interface letting a customer's assistant call the vendor is extensibility; it says nothing about who picks the model. That fact now sits only on Ext. WHAT ACTUALLY CARRIES IT IS STRONGER THAN WHAT WAS CITED. AgentCreator ships LLM Snap Packs for CLAUDE, OPENAI, AZURE OPENAI, GOOGLE GEMINI AND AMAZON BEDROCK, each a separate configured account the builder chooses. The vendor states its own position plainly on the security page: the platform is AGNOSTIC REGARDING AI AND LLM MODELS, GIVING CUSTOMERS THE FLEXIBILITY TO CHOOSE solutions that meet their business and compliance needs. THE DETAIL WORTH CARRYING is that model choice is a procurement and compliance lever here, not just a quality one. Custom endpoint accounts route LLM calls through an API management proxy so an organisation can enforce policies on which models are reachable and how, with plain, OAuth2 and header-transformation variants. A platform that lets a customer put its own gateway in front of model access is solving the governance problem that decides whether a regulated buyer can use any model at all. An AI gateway added in April 2026 extends this with consistent support across providers spanning eight capability dimensions, so switching provider does not mean rebuilding. One honest limit, recorded rather than penalised: model selection is per-Snap configuration rather than a routing engine that picks between models at runtime. This axis measures customer choice, which is amply met; it does not require automatic routing.

Stands at F, and the MCP Server is the material change the July build did not have. THE VENDOR STATES THE DIRECTION ITSELF, WHICH IS UNUSUALLY CLEAN FOR THIS AXIS: the MCP SERVER FEATURE EXPOSES SNAPLOGIC PIPELINES AS AI TOOLS THAT ANY MCP-COMPATIBLE CLIENT CAN DISCOVER AND INVOKE, and the documentation draws the distinction explicitly, AgentCreator builds agents that run inside SnapLogic while MCP Server makes pipelines available to EXTERNAL AI AGENTS AND CLIENTS SUCH AS CLAUDE. That is the customer's assistant calling the vendor, which is the Ext direction and precisely why it earns nothing on Model. WHAT MAKES THIS STRONGER THAN A TYPICAL MCP CREDIT is the surface area. It is not a handful of hand-built tools: any pipeline the customer has already built, including the thousand-plus connectors underneath, becomes discoverable and invocable. A twenty-year integration estate turns into an agent tool catalogue through one feature. The conventional developer surface is also fully present, and would carry Full on its own under the 30 August bar. Triggered Tasks expose any pipeline as an HTTP web API endpoint with the OPEN API SPECIFICATION SUPPORTED and endpoints downloadable in API form, there is a public REST API for platform operations, API management is a first-class product, and custom Snaps let developers build and package their own components. SnapCode, added in 2026, extends the code-side surface further. A Groundplex-hosted Triggered Task can sit behind the customer's own load balancer, so the extensibility surface does not force traffic through the vendor's cloud.

Stands at P under the 31 August Eval bar, and this is a closer call than the grade suggests, so the reasoning is recorded rather than left implicit. THE DEBUGGING HALF IS GENUINELY STRONG and better than the July basis conveyed. Builders inspect reasoning steps, tool calls and results; the pipeline holds the full conversational history specifically to debug individual operations at each iteration; the Agent Visualizer exposes agent reasoning; and Prompt Composer is a dedicated console for refining prompts and viewing responses in one UI. This axis is named testing-debugging-optimization and the debugging and optimisation limbs are well served. THE TESTING HALF IS WHERE IT STOPS SHORT. The vendor documents ENHANCING AI OUTPUT QUALITY BY LEVERAGING OTHER LLMS FOR EVALUATION AND SCORING, which is model-as-judge scoring and does produce a readable result, plus AI response validation in the governance set. What is missing is comparability: no test set or golden dataset object, no stored expected outputs, no scored run history, and nothing that lets a customer establish whether version two of an agent is better than version one on the same inputs. Under the ruled bar, Full needs a result the customer can read AND COMPARE about the agent's behaviour on their own work. A judge score with nothing to hold it against is half of that. The contrast with sema4-ai's one-click evaluations, created from real conversations and used to test model upgrades against the same scenarios, is exactly what the second half looks like when present. I record that this is arguable in the other direction: an evaluation-and-scoring pattern plus stored pipeline runs could be assembled into comparison by a determined customer. But assembling comparison from primitives is not the same as the platform documenting it, and grading the possibility would be grading what a customer could build rather than what the vendor ships. Consistent with codebuff and warp, both held at Partial on real measurement without a customer-runnable comparable harness.

Stands at N, and confidence rises from medium to high because the architecture settles it rather than a search failing to find anything. The July basis was one of the more accurate cells on this record. Everything an agent does here runs through a Snap, and a Snap connects to a third-party API endpoint. That is the definition of a programmatic interface, so the axis is answered structurally: the platform's entire premise is that a documented integration exists. Comp is non-zero only where an agent operates software BECAUSE no programmatic interface exists, which is the case SnapLogic is built to make unnecessary. No browser control, navigation, form filling, screen interaction, visual grounding or desktop automation appears in the AgentCreator documentation, the Snap Pack catalogue, the product pages, the data sheet or the 2026 release notes, and the vendor makes no claim in that territory anywhere. ONE NEAR-MISS CHECKED AND REFUSED, since it is the kind that has been miscounted elsewhere in the index: the utilities that parse HTML alongside PDF, Markdown and unstructured content. Parsing retrieved HTML is document handling, credited on Know. Reading a page's markup is not driving a browser, and the distinction is the same one applied to the scraping and screenshot refusals throughout this lane. For the lane record, this is a clean negative reference point of a specific kind: a vendor with enormous reach into enterprise systems and none of it through an interface. It pairs usefully against sema4-ai, which reaches Full on this axis from an RPA lineage, to show that breadth of system access and computer use are genuinely different properties.