Skip to content
SparQ

Platform

One platform for the whole life of an agent.

Most teams stitch an agent together from a model SDK, a vector store, a queue and a dashboard, then rebuild it for the next product. SparQ gives every agent the same five chapters, under the same rules, in one place.

The life of an agent

Build, host, deliver, maintain, stay current.

Five chapters every agent goes through. SparQ is the one place all five happen, under the same rules.

  1. IBuild

    Describe the agent. Don't hard-code it.

    An agent on SparQ is a specification stored as data: its job, its instructions, the class of model it needs, the tools it may call, the skills it can load and the actions that must wait for a person. Your developers write it once; your product owners can change it later without a code release.

    • Skills load only when they are relevant, and never grant a tool
    • Your tools arrive over MCP, or as operations imported from your OpenAPI document
    • Hard limits on model calls, tool calls, delegation depth and run time
    • A Python kit to validate specs and run evaluations on your laptop
    agent: triagemodel:reasoningtools:orders.*approve:refundslimit:20 callsvalidateSKILL.mdrefund policyMCP toolschema pinned
  2. IIHost

    Run it on a platform built for many customers.

    Most AI features serve more than one customer. SparQ is built for that from the first table: every row carries the workspace, the project, the client and the environment, and the database itself refuses to show one client's data to another.

    • Row-level security on every table; no SparQ role can bypass it
    • Complete, repeatable data planes, called stamps, inside each geo
    • Development keys are refused by production, and production access is never implied
    • Runs are checkpointed after every step and survive a restart
    geo: eustamp eu-1stamp eu-2one lane per client, sealed by RLS
  3. IIIDeliver

    Put it in front of people, three ways.

    A chat panel that streams its answer, an action button that returns one typed result, or a background job that runs while nobody watches. All three use the same contract, your own users' sign-in, and the same pause when an action needs a person.

    • Streamed events: tokens, plans, tool progress, citations, questions, approvals
    • A typed TypeScript client and a React chat kit with approval cards
    • Your identity provider, verified properly: RS256 or ES256, never a shared secret
    • Your application never holds a model key
    approval_requiredrefund $42?approve
  4. IVMaintain

    Know what every agent did, and what it cost.

    Every model call is one row in a usage ledger with the client, agent, model class and credential that caused it. Every action is one record in an append-only audit chain. Budgets are reserved before a call is sent, so a looping agent stops at its limit instead of at your invoice.

    • Budgets from the single run up to the whole workspace, with hard stops
    • A hash-chained audit log, written in the same transaction as the action
    • OpenTelemetry traces to the tools you already run, with prompt content off by default
    • Kill switches for an agent, a tool or a model, effective in seconds
    ledgerbudget 72%#81#82#83#84#85
  5. VStay current

    Take the better model without touching the app.

    Agents ask for a class of model, never a model by name. When a better or cheaper model arrives, the change is a new Release of your Project: evaluated against your own test suites, approved by a second person, promoted as a whole, and rolled back in one step if it disappoints.

    • Model classes: reasoning, standard, fast, code, vision, embed and rerank
    • A Release cannot reach an environment unless its evaluations pass
    • Runs already in progress finish on the version they started with
    • The author of a change can never approve it
    r40r41r42r43reasoningevals

Who it is for

One platform, four people who all have to say yes.

Developers

One contract instead of a model zoo.

  • REST and server-sent events, versioned, with breaking changes caught in CI
  • Typed clients generated from the same contract the API is built from
  • No provider keys, retries or token counting in your code

Platform and security teams

One place to enforce what every agent may do.

  • Default-deny tool gateway with pinned schemas and egress control
  • Credentials scoped per environment, revoked in seconds
  • An audit trail you can verify end to end

Product and business owners

Change behaviour at business speed.

  • Edit instructions, skills and tools in a console, not a sprint
  • See quality and cost change before you approve
  • Spend by customer, feature and agent, from the same ledger

Compliance and legal

Evidence, not assurances.

  • Residency per client, enforced where every model call is made
  • Every deployment states its training and retention terms
  • A data-location record for every call, exportable per client

The catalogue

Everything between your application and the model.

Each capability carries its availability. Open one to see how you use it.

Early access
Built and tested. Available to early-access workspaces.
Next release
Designed and scheduled. Not available yet.
Roadmap
Designed. Scheduled once the product decision is made.
  • Frontier Gateway

    Early access

    One governed way to call any model. Agents ask for a class of model (fast, standard, reasoning, code, embed, rerank or vision), and the gateway chooses the deployment.

    • One request, response and stream format over the official provider SDKs
    • Retries with jitter, a circuit breaker per deployment, and fallback that stays inside the allowed list
    • Each routing decision recorded: rules applied, candidates removed, deployment and region chosen
    • Azure OpenAI and any OpenAI-compatible server today, including self-hosted open-weight models
    Usage: Read the model classes your workspace can use
    curl https://api.sparqhq.ai/v1/admin/model-classes \
      -H "Authorization: Bearer $SPARQ_KEY"
  • Clients and compliance profiles

    Early access

    Built for applications that serve many customers. Each of your customers is a client inside your Project, with its own data, memory, traces and budget, isolated by design.

    • A compliance profile per client: allowed regions, allowed providers, provider retention and data sensitivity
    • Model routing obeys the profile and fails closed with no_compliant_model, never quietly routing elsewhere
    • The client comes only from a verified claim in your user's token, never from a request header
    Usage: Keep one client's data in the EU
    curl -X PUT https://api.sparqhq.ai/v1/admin/audience-tenants/$CLIENT_ID/compliance-profile \
      -H "Authorization: Bearer $SPARQ_KEY" \
      -H "Content-Type: application/json" \
      -d '{ "audience_tenant_id": "'$CLIENT_ID'", "version": 1,
            "data_regions": ["eu"], "allowed_providers": ["azure-openai"] }'
  • Usage ledger, budgets and limits

    Early access

    Every model call is one ledger row with every dimension you need to attribute it: workspace, project, client, agent, model class, credential, tokens and cost.

    • Budgets reserved before each call, from the run up to the workspace, plus a cap per credential
    • A hard limit stops the call before it is sent; delegation cannot multiply spend
    • Rate limits per credential and per client, refused when the limiter cannot be reached
    • Usage reports grouped by client, agent, model class, project, credential or day
    Usage: Spend by client and model class, last 30 days
    curl "https://api.sparqhq.ai/v1/admin/usage/report?group_by=audience_tenant&group_by=model_class" \
      -H "Authorization: Bearer $SPARQ_KEY"
  • Audit and traceability

    Early access

    Every request records the credential that made it. Audit records are append-only, chained by hash per workspace, and written in the same transaction as the action they describe.

    • If the audit write fails, the action is undone
    • A verifier detects changed, removed and re-hashed records
    • Every authorization decision is recorded with its policy version, including refusals
    Usage: Read the audit trail for one credential
    curl "https://api.sparqhq.ai/v1/admin/audit?credential_id=$CREDENTIAL_ID" \
      -H "Authorization: Bearer $SPARQ_KEY"
  • Feature settings with inheritance

    Early access

    End-user features such as file uploads, web search or memory are switched on and off at six levels: platform, workspace, project, client, user and conversation.

    • A lower level can only narrow what the level above allows
    • Admins can lock a setting so nobody below can change it
    • Enforced on the server, not only hidden in the interface
    Usage: Read a project's feature settings
    curl "https://api.sparqhq.ai/v1/admin/feature-settings/project?scope_id=$PROJECT_ID" \
      -H "Authorization: Bearer $SPARQ_KEY"
  • Agents, skills and Loop Engineering

    Next release

    Agents are specifications stored as data, not code: job, instructions, model class, tools, skills, limits and the actions that need approval.

    • Modes: react, deep, research, workflow and loop
    • Loop mode runs Discover, Plan, Execute, Verify, Iterate, and the checker is never the maker
    • Skills load only when relevant, and a skill never grants a tool
    • Hard limits on model calls, tool calls, delegation depth and run time
    Usage: Run an agent from an action button
    curl -X POST https://api.sparqhq.ai/v1/runs \
      -H "Authorization: Bearer $USER_TOKEN" \
      -H "Content-Type: application/json" \
      -d '{ "agent": "ticket-triage", "input": { "ticket_id": "T-1042" }, "wait": true }'
  • Your tools, through one gateway

    Next release

    SparQ never runs your code. Your services expose tools over MCP, or SparQ imports operations from your OpenAPI document, and every call passes the tool gateway.

    • Schema validation, authorization, approval, egress policy and audit on every call
    • Tool schemas are pinned; a changed schema is blocked until it is reviewed
    • Tools receive a short-lived, single-purpose token (ES256, at most five minutes), never the user's own token
    • Tool output is treated as untrusted data and screened for injection
    Usage: Verify a delegated token in your tool server
    # Public keys for delegated tool tokens
    curl https://api.sparqhq.ai/.well-known/jwks.json
  • Knowledge with citations

    Next release

    Collections of documents that agents search by name: hybrid search over vectors and full text, with citations on every answer.

    • An agent searches only the collections it names
    • It sees the shared part plus its own client's part, never another client's
    • Per-collection settings for result count, minimum score and required citations
    Usage: Search a collection
    curl -X POST https://api.sparqhq.ai/v1/admin/collections/$COLLECTION_ID/search \
      -H "Authorization: Bearer $SPARQ_KEY" \
      -H "Content-Type: application/json" \
      -d '{ "query": "refund policy for annual plans" }'
  • A person in the loop

    Next release

    Agents stop to ask a question or to request approval, and resume later in any process. Writes and destructive actions always wait for a person.

    • Approval is forced for writes, spend past the soft budget and outside destinations
    • Approve, reject, or edit the arguments before the tool runs
    • Pauses survive restarts: state is checkpointed after every step
    Usage: Approve a pending action
    curl -X POST https://api.sparqhq.ai/v1/approvals/$APPROVAL_ID \
      -H "Authorization: Bearer $USER_TOKEN" \
      -H "Content-Type: application/json" \
      -d '{ "decision": "approve", "comment": "Refund confirmed with the customer" }'
  • Releases with a quality gate

    Next release

    A Release is an immutable bundle of a Project's configuration: models, instructions, agents, tools, guardrails, knowledge and the evaluation baseline. It is promoted and rolled back as a whole.

    • Draft, validate, evaluate, review the diff with its quality and cost change, then a second admin approves
    • A Release cannot reach an environment unless its evaluation suites pass
    • Live within seconds; runs already in progress finish on the version they started with
    • One-step rollback
    Usage: Roll production back to an earlier Release
    curl -X POST https://api.sparqhq.ai/v1/admin/projects/$PROJECT_ID/rollback \
      -H "Authorization: Bearer $SPARQ_KEY" \
      -H "Content-Type: application/json" \
      -d '{ "environment": "prod", "to_release_id": "'$PREVIOUS_RELEASE_ID'",
            "reason": "Answer quality dropped after the last Release" }'
  • Observability without lock-in

    Next release

    OpenTelemetry traces with the GenAI conventions, sent to the tools you already run: Grafana, Langfuse, Datadog, Azure Monitor or any OTLP backend.

    • Prompt and response content is off by default
    • Content policy per destination: metadata only, redacted, or full with an approver
    • A residency check on every destination
    Usage: List traces for a project
    curl "https://api.sparqhq.ai/v1/admin/traces?project_id=$PROJECT_ID" \
      -H "Authorization: Bearer $SPARQ_KEY"
  • SDKs and UI kits

    Next release

    A typed TypeScript client with streaming, a React chat kit with approval and question cards, and a Python SDK for specs, drafts and local evaluation runs.

    • Types generated from the same contract the API is built from
    • The SDK never holds model keys, evaluates policy or stores memory
    • Consoles call the API from their own server, so keys never reach a browser
    Usage: Typed stream events in TypeScript
    import type { Schema } from "@sparq/client";
    
    function render(event: Schema<"StreamEvent">) {
      if (event.type === "token") append(event.text);
      if (event.type === "approval_required") showApproval(event.approval);
    }

Give your next AI feature a contract that outlives the model.

Tell us what you are building. We will show you SparQ on your use case and your residency rules.

Early access: Built and tested. Available to early-access workspaces.