| When changes are madea new capability arrives mid-conversation, or after a build-and-publish cycle | ✓during the conversation — the running session gains the capability immediately, no publish step | ◐Clark authors from natural language, but through Plan → Build → checkpoint → publish, driven by a builder; the app changes when someone ships it | ✕a developer writes code, then redeploys | ✕guidelines and tools are configured through the SDK/UI ahead of time, then served | ✕design-time work in the visual builder, then publish | ◐edits files live, but the change lands in source you still have to run or deploy | ◐GPT Builder is a separate authoring flow, not something that happens mid-conversation | ◐Flows and Automate are built by a user or admin ahead of time, then run; the chat assistant does not gain new capabilities mid-conversation |
|---|
| What you end up witha running governed agent, or a codebase somebody now owns | ✓a running agent — tools, processes and screens live in the platform, with nothing added to your source tree | —different shape by design: the deliverable is a React/Python/SQL app your team owns, reviews in an IDE and maintains — traceable code is the whole point | —different shape (a codebase your developers write and keep) | —different shape (an engine you embed, with tools you write) | ◐a bot configuration that lives in and is maintained through the designer | —different category (edits to source in your repo) | ◐a configured GPT, not a maintainable artifact you can diff or review | ◐an assistant plus flows, agents and apps maintained inside Quick — configuration in the platform, not something you diff or review |
|---|
| Where the rules come fromtaken from the process a business owner wrote, or configured up front by an admin | ✓the process the business owner wrote is the control itself — it is turned into a check that gates every action | ◐mature and broad — RBAC/ABAC on Okta or Entra, audit events, secret abstraction, PII masking, a security pass before publish — but all of it is org policy an admin configures once and Clark then conforms to, rather than a process machine derived from the SOP itself | ◐a coded graph structurally cannot take an edge that does not exist, but a developer writes that graph — it is not derived from the document a business owner wrote | ◐guidelines shape the dialogue, but there is no compiled, validated process machine behind them | ◐the flow engine constrains what is reachable, but the flow is hand-built in a designer, not written as prose by the process owner | —different category (no business-process governance model) | ✕no equivalent | ◐admin governance — custom permissions, IAM-based access and CloudTrail logging — configured once by an admin; no process written by its owner is turned into a check |
|---|
| Role-based access controlwhich roles may use which capability, enforced at the point of use | ✓a DB-driven permission module gates tools and processes themselves, not just endpoints — and roles, permissions and assignments are administrable at runtime through the agent | ✓mature and thorough — RBAC/ABAC inherited from Okta or Entra, enforced down to pages, queries and individual rows | ✕no framework access-control model — a developer builds one | ✕no built-in role model documented | ✓enterprise RBAC is a standard part of the platform | ◐permission modes gate which tools may run, but for one local developer — not roles across an organisation | ◐workspace roles exist on enterprise tiers, but they do not gate individual tools or actions | ✓custom permissions and IAM policy assignments control which users and groups reach which features and connectors — admin-configured at the platform level, not per process or per action |
|---|
| Human approval gatesa step stops and waits for a person before the action goes through | ✓built in — confirmation gates on sensitive actions, blocking ask-user steps, and process states that refuse a call arriving out of order | ◐an approval can be built into a workflow as a step, but it is something a builder wires into that flow, not a gate the platform applies to any action | ◐LangGraph interrupts give real human-in-the-loop pauses, but a developer places every one of them | ◐a guideline can tell the agent to confirm first, but that is an instruction the model follows, not a gate that denies the call | ◐approval nodes can be designed into a dialog flow by a bot builder | ◐built-in — it asks before edits and commands, though it is a developer approving their own tool call, not a business approval path | ✕no per-action approval gate | ◐a step can be built into a flow, but third-party analysis reports that Quick's own approval workflows currently cover sharing only — not a gate the platform applies to any action |
|---|
| Verifiable recordevidence a third party can check, not just a log you are asked to trust | ✓the conversation record is signed, and an export ships with integrity evidence that can be verified independently of the system that produced it | ✓searchable organisation-wide audit events across every interaction — comprehensive, though not published as a signed, independently verifiable export | ◐LangSmith traces every run in detail, but as observability for debugging, not a tamper-evident record | ◐session logs exist, but no signed or exportable audit artifact | ✓enterprise audit logging is a standard part of the platform | ◐transcripts and session logs sit on the local machine, with no signed export | ◐enterprise tiers can export conversations for compliance, but that is chat history, not a signed record of actions taken | ◐activity is logged to AWS CloudTrail — a solid audit trail, but an AWS-held log rather than a signed export a third party can verify |
|---|
| Identity and SSOwho the caller actually is, established on verified claims | ✓native OAuth2/OIDC with signature-verified claims, alongside bearer, cookie and host-token resolvers behind one resolver registry | ✓SSO through Okta or Entra, and embedded apps authenticate via Auth0/OAuth | ✕no framework identity model — entirely on the developer | ✕no framework identity model | ✓SSO, SAML and OIDC are standard enterprise features | —different category (a local tool running as one developer) | ✓SAML/SSO on enterprise tiers | ✓IAM Identity Center and federated identity providers |
|---|
| Keeping tasks separateeach task sees only its own tools and data, so banking never leaks into retail | ✓automatic, no code — inferred per request | ◐apps are separate and permissions run down to pages, queries and rows, but the boundary is an app a builder drew up front, not a split inferred per request | ◐possible, but a developer must hand-design the graph — not automatic | ✕guidelines apply within one agent's dialogue — no automatic per-domain tool/context split | ◐multi-bot orchestration routes between bots/skills, but the split is designed and wired by a bot builder, not inferred per request | ◐built-in sub-agents isolate context, but a person must invoke them each time | ✕single shared thread | ◐spaces and connectors scope what a user or agent can reach, but the boundary is drawn by an admin or builder, not inferred per request |
|---|
| Splitting work into dependent tasksa task waits for the one it depends on, then carries on automatically | ✓automatic — the model invents the graph itself, live, no code | ✕Clark builds workflows with steps and triggers, but they are authored artifacts published ahead of time — not a graph invented live, and not caller-blocking | ◐a true DAG, but a developer must author every node/edge in code beforehand — not automatic | ✕Journeys are ordered flows authored by a developer in code — no model-invented task graph, no automatic caller-blocking | ◐Dialog Tasks are visual flows built in a no-code designer, not invented live and not a blocking dependency graph | ◐built-in flat checklist, no dependency blocking — no code needed, just weaker | ✕no exposed task graph | ◐Flows are authored multi-step workflows, and Quick Research plans its own research steps — but there is no caller-blocking dependency graph invented live |
|---|
| Steps that cannot be skippedout-of-order or skipped steps are refused by the system, not just discouraged in a prompt | ✓automatic — the written process is turned into a runtime check, switched on per process | ◐a published workflow runs exactly the steps it was built with, and approvals can be wired into it — but nothing validates a process description into a machine, and no check refuses a call for arriving out of order | ◐a real strength here — a coded graph structurally cannot take an edge that does not exist — but a developer writes that graph in code; it is not derived from the same document a business owner wrote | ◐Journeys shape the conversation, but there is no published mechanism that hard-denies a tool call for skipping or reordering a step — it leans on guideline matching, not a compiled, validated graph | ◐Dialog Task flows run on a flow engine, so a node's actions are structurally the only ones reachable from it — but that flow is hand-built in a visual designer, not derived from a natural-language process description | —different category (no business-process state machine concept) | ✕no equivalent | ◐a flow runs the steps it was built with, but nothing validates a process description into a machine, and no check refuses a call for arriving out of order |
|---|
| Changing the system while it runsadd or change tools, processes and screens: check → test → version → switch on, with no source edit and no redeploy | ✓automatic — compiles, tests and versions itself, no developer touches source | ◐the closest peer on this row: Clark writes apps, workflows and jobs from natural language, with checkpoints and publish giving real versioning and rollback — but it authors a codebase for a builder to review and ship, not capabilities an agent grants itself mid-task | ✕tools are always hand-written code by a developer — no in-conversation authoring | ✕guidelines are configured through a UI/SDK by a developer; tools are hand-written Python functions — no in-conversation authoring | ✕dialog flows and API "Actions" are built by a bot developer in the visual designer — no live authoring by the agent itself | ◐built-in — it can write/edit files directly, but that's editing real source with no sandboxed draft/version/rollback | ◐built-in GPT Builder configures tools, but as a separate authoring flow with no version/rollback | ◐users can build flows and apps from natural language with no code — but not capabilities an agent grants itself mid-task, and no sandboxed check → test → version → switch-on cycle is documented |
|---|
| Tidy conversation memorya clean snapshot each turn, not an ever-growing log | ✓automatic every turn | —different category (an app builder, not a long-running conversational runtime) | ◐built-in — LangGraph checkpoints full state per node, a different (also code-free at runtime) model | —not documented as a distinct mechanism; conversation state is session-managed by the engine | —not documented as a distinct mechanism; dialog state is tracked via context/session variables | ✕append-only transcript + auto-compact | ✕append-only conversation | —not documented as a distinct mechanism |
|---|
| Keeping what matters in long conversationsevicts low-value data, keeps exact records the task is actively using | ✓automatic budgeted eviction + stub-and-reread | —different category (the build session is short-lived; the published app holds no conversational context) | ◐summarization memory classes exist, but a developer must wire and configure them | —no published equivalent | —no published equivalent | ◐built-in auto-compact, coarser than a keep-list — no code needed, just less precise | ◐built-in background summarization — automatic, but not configurable by anyone | —not documented as a distinct mechanism |
|---|
| Long-term recall of exact original datarestores the real structured record, not a paraphrase | ✓automatic — one tool call restores the original structure | —different category — a published app queries your database live, so there is nothing to recall; no store of past tool payloads | ◐vector retrieval is available, but a developer must assemble and tune the whole RAG pipeline | ✕no persistent cross-session recall documented as a core feature | ◐context/session variables and profile fields persist facts, but not a general tool-payload recall store | ✕no persistent cross-session recall by default | ◐built-in memory stores discrete facts, not tool-call payloads | —not documented as a distinct mechanism |
|---|
| Automatic lessons-learned capture & self-correctiona user correction is written down, tagged, and fixed if it later goes stale | ✓automatic, tagged, self-correcting — no user action needed | ◐genuinely close: org, app and user knowledge tiers persist standards, and Clark updates org knowledge as the team builds — but it captures build conventions, not a tagged, self-correcting record of a correction made mid-task | ✕no built-in equivalent — a developer would have to build this from scratch | ✕no built-in equivalent — a developer would have to build this from scratch | ✕no built-in equivalent — corrections mean a bot builder editing the flow by hand | ◐CLAUDE.md persists notes, but a person must write and maintain it — nothing is auto-captured | ◐built-in memory can save a stated correction, but it's not a tagged, self-correcting store | —not documented as a distinct mechanism |
|---|
| Separate rules per area"always ask before >£100" for banking, "always °C" for weather — independently | ✓automatic, global or per-domain | ◐knowledge is scoped three ways — org, app and user — which is real scoping, but it steers how Clark builds, not how a running agent behaves in one business domain versus another | ✕no built-in preference system — a developer would build one | ✕no built-in per-domain preference system | ✕no built-in per-domain preference system — behavior differences mean separate bot configuration | ◐CLAUDE.md is project-scoped and manually written, not per-capability | ✕memory is global/flat, not domain-scoped | ◐instructions can be set per custom agent or space, but they are configured by hand, not captured and scoped automatically |
|---|
| Knowledge base correlating facts across many documentsanswers a question no single stored document can answer alone | ✓automatic — hybrid search, persists & grows across sessions | ◐org knowledge is centrally managed with RBAC and a full audit trail, but it holds build-time standards and conventions, not a retrieval corpus for answering business questions | ◐RAG is possible, but a developer must assemble the entire pipeline (chunking, embeddings, store, retrieval) | ◐tool calls can hit an external retrieval system, but assembling and tuning it is on the developer | ✓built-in Search AI/SmartAssist indexes documents for Q&A — a strong, mature feature | ◐built-in — strong within a repo's files via grep/read, but not a persistent cross-session KB | ◐built-in file search cites sources, but only within a session's uploads | ✓Quick Index and Quick Research search connected business data and the web with citations — a strong, mature feature, and wider in connector coverage than Codexta |
|---|
| Screens that can be changed liveproduct grids, tables, custom cards the agent can also edit on request | ✓automatic — ready-made components, editable at runtime, no code | ◐the strongest UI story in this table — Clark generates real React, conforms to your design system, and syncs IDE edits back to the visual view — but components are generated and published at build time, not authored live inside a running conversation | —different category (backend framework, no UI layer) | —different category (a conversation engine; rich UI is up to the channel/frontend you build) | ◐per-channel rich message templates (cards, carousels) are supported, but configured at design time — not authored live by the agent | —different category (terminal output, not a UI runtime) | ◐built-in canvas/rich responses, not an extensible component system | ◐a no-code app builder produces interactive tools and forms, but they are built ahead of time, not edited live by the agent inside a conversation |
|---|
| Passwords the AI never seesa typed password never reaches the AI in readable form | ✓automatic — encrypted client-side, substituted only inside the tool call | ✓abstracts secrets behind the integration layer and holds them in data-plane environment variables inside your own network, with PII masking on top — the value need never reach the model | ✕no framework guarantee at all — entirely up to how a developer wires each tool | ✕no framework guarantee — depends on how each tool function is written | ◐enterprise-grade masking/PII redaction options exist, but as configurable policy, not a structural guarantee the model never sees the value | —different category (not a login-flow agent) | ✓built-in — Actions can use OAuth, token held by the platform (requires configuring an Action) | —not documented as a structural guarantee that the model never sees a typed secret |
|---|
| Run on your own AI modelsno vendor lock-in to one model provider | ✓automatic — any OpenAI-compatible endpoint, no code | ◐hybrid data planes run in your network (ECS, Cloud Run, Kubernetes, Azure, Docker) and the LLM provider is configurable per workspace, Bedrock included — but the control plane stays Superblocks Cloud and Clark is not a model you host | ✓genuinely model-agnostic too (swapping providers still means updating your integration code) | ✓genuinely model-agnostic and self-hostable — a real strength of the project | ◐supports bringing your own LLM (incl. Azure-hosted models) and on-prem/VPC deployment, but as an enterprise contract/config, not an open self-host | ✕tied to Claude models | ✕tied to OpenAI models | ✕runs on AWS-managed models through Bedrock; no bring-your-own OpenAI-compatible endpoint is documented, and cross-Region inference is reported as not configurable |
|---|
| Embeddable into an existing sitee.g. a retailer bolts it onto their own e-commerce site | ✓a first-party drop-in web widget — one script tag and a single setup call add a launcher and chat panel to any site, sealed off from the page’s own styles and scripts, with the host site’s signed-in user passed through — plus native mobile SDKs for apps | ✓first-party embedded applications with Auth0/OAuth authentication and programmatic deployment | ◐same story — it's a backend library, a developer builds the API + front-end widget from scratch | ◐same story — it's a backend engine, a developer builds the widget | ✓ships first-party web and native mobile SDKs to drop the widget into an existing site | —different category (a local CLI/IDE tool, not a website embed) | ◐the Assistants/Chat API can be embedded, but again a developer builds the widget — no first-party "drop into your site" product | —different category — a workforce assistant for your own staff, not a widget you drop into your customers' site |
|---|
| White-label brandingyour name, your colours, your domain — no "powered by" badge | ✓config-driven — one file controls name, colours & domain, so the whole surface ships under your brand | ✓embedded apps carry your own design system, so what ships looks like your product | ◐it's your own frontend code either way, so branding is entirely up to what a developer builds | ◐open source and unbranded by default, so branding is whatever you build around it | ✓white-labeling is a standard enterprise offering | —different category (a local CLI/IDE tool, not a customer-facing product) | ✕ships as OpenAI/ChatGPT-branded, no white-label option | —different category — an AWS-branded workplace product, not a customer-facing surface |
|---|