Skip to main content
Connic

Build agents.
Connic handles operations.

Version runtime settings in Git alongside your agent code. Connic handles builds and deployments, manages concurrency and retries, and provides execution traces and rollbacks.

Start for freeSee the deployment walkthrough
Read the deployment docs
  1. 1

    Package

  2. 2

    Build

  3. 3

    Test

  4. 4

    Activate

  • customer_acme
    tool: ledger.lookup
    running
  • customer_acme
    waits for the active key
    queued
  • customer_north
    waits for the agent-wide slot
    queued

The agent is a small part of the system that runs it.

Once model calls and Python tools are ready, production still needs builds, release gates, concurrency, retries, sessions, and rollback. Connic manages those controls on the same run and deployment model.

Release
Build the image, run any required deploy gate, and activate a deployable version
Execute
Bound iterations, time, retries, and simultaneous runs
Coordinate
Queue or drop conflicting work by a payload key
Recover
Keep the active version serving and reactivate a prior deployment

Define how your agents run

Configure execution limits and concurrency per key directly in the agent file. Keep the settings versioned and easy to review.

agents/invoice-processor.yaml
version: "1.0"

name: invoice-processor
type: llm
model: connic/gpt-5.6-sol
description: "Validates and routes incoming invoices."
system_prompt: "Validate the invoice, look up its ledger state, then assign its review queue."

tools:
  - ledger.lookup
  - routing.assign_queue

max_concurrent_runs: 1
max_iterations: 40
timeout: 120

retry_options:
  attempts: 5
  initial_delay: 10
  max_delay: 60

concurrency:
  key: "data.customer_id"
  on_conflict: queue
  • customer_acme
    tool: ledger.lookup
    running
  • customer_acme
    waits for the active key
    queued
  • customer_north
    waits for the agent-wide slot
    queued
  • customer_orbit
    waits for the agent-wide slot
    queued
  • customer_south
    waits for the agent-wide slot
    queued
Different keys can run in parallel when max_concurrent_runs is above 1. The setting on_conflict: drop cancels duplicate work instead of queueing it.

  • Bound the loop

    Limits cap simultaneous runs, LLM iterations, and wall-clock execution per agent.

  • Retry the failing operation

    Model requests retry at the call; the runtime does not replay the whole LLM agent.

  • Serialize one business key

    Per-key serialization works alongside the agent-wide run limit.

Check new versions before they go live

Deploy through Git or the CLI. Connic runs existing tests and activates only versions ready to run. Failed attempts remain available for review. Tests can be skipped from the CLI or for a manual Git deployment in the dashboard.

  1. 1

    Package

    Agent spec + Python

  2. 2

    Build

    Dependencies installed

  3. 3

    Test

    Deploy gate passed

  4. 4

    Activate

    Traffic moved

Candidate failed

Build or deploy-gate failure marks that deployment failed.

Active version keeps serving

Traffic remains on the last active deployment without interruption.

Define what happens when something fails

Configure how Connic responds to provider errors, conflicting requests, iteration limits, and failed deployments.

Runtime responses to common failures
FailureRuntime response
Model request failureRetry with backoff, or switch to fallback_model and apply its retry budget.
Conflicting keyQueue the new run or drop it, according to the agent's concurrency rule.
Iteration ceilingStop the LLM loop instead of allowing repeated tool calls indefinitely.
Failed releaseLeave the active deployment serving and retain the failed build logs for inspection.

  • Rollback without rebuilding

    A prior successful deployment can be activated to route traffic back to its existing container.

  • Sessions persist across releases

    Enabled session history remains available across restarts and redeployments.

  • Trace each run end to end

    The active runtime records model calls, tools, middleware, guardrails, and orchestration under the run that executed them.

Limits, retries, concurrency, sessions, and deployment behavior are documented in detail. Runtime controls or deployment lifecycle.

Keep exploring

Environments

Separate config, secrets, and releases.

Testing

Gate every deployment with real cases.

Observability

Inspect every step of every run.

Connectors

Bring production events into the runtime.

Guardrails

Enforce checks before and after execution.

Dev Server

Use the cloud runtime in a fast edit loop.

Frequently Asked Questions

A Git-connected project deploys when a push reaches the branch mapped to an environment. A project without a Git connection can deploy through the Connic CLI. Connic packages the agent project, builds its container, and runs the full suite when tests/ exists. For manual deployments, the test phase can be skipped with --skip-tests in the CLI or Deploy & skip tests in the dashboard; automatic Git deployments always run it. A deployable candidate can then become active.

The candidate deployment is marked Failed and the currently active deployment keeps serving traffic unchanged. Build logs remain available on the deployment detail page for investigation.

Yes. A previous successful deployment can be activated from the Deployments tab. Traffic is routed to that deployment's existing container, so no new build is required.

Not for an LLM agent. Model requests retry at the failing call, while failed tool calls are reflected back to the agent. Tool and sequential agents retain operation-level retries, and rerun_middleware applies only to those operation-level retries.

A concurrency key is read from the raw trigger payload. Only one run for the resolved key is active at a time; a conflicting run either waits in a queue or is dropped. Runs with different keys can still execute in parallel, subject to max_concurrent_runs and the project plan.

Yes, when session history is enabled. Conversation history remains available across requests, restarts, and redeployments until its optional inactivity TTL expires or the session is deleted.