Skip to main content
Connic

Deploy agent code on a
managed runtime.

Version runtime controls beside your agent. The same execution model handles builds, activation, retries, keyed concurrency, traces, and rollback.

Start with BasicSee 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 production gap

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
Runtime contract

Put the failure boundaries in the agent spec

Execution limits and per-key concurrency live in reviewable agent configuration.

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

name: invoice-processor
type: llm
model: connic/gemini-3.7-flash
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. Set on_conflict: drop when duplicate work should be cancelled instead.

  • Bound the loop

    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

    Apply per-key serialization alongside the agent-wide run limit.

Release path

A deployable version becomes active. A failed candidate stays in history.

Git-connected projects deploy from mapped branches; other projects use the CLI. Tests run when a suite exists unless a CLI deployment explicitly uses --skip-tests.

  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.

Operations

Define recovery behavior before a failure

Configure responses for provider errors, conflicting events, iteration limits, and failed releases.

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

    Activate a prior successful deployment and route traffic back to its existing container.

  • Sessions persist across releases

    Persistent sessions retain conversation history across restarts and redeployments when a session key is configured.

  • 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. Inspect the runtime controls or follow the 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 you push to 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. The CLI-only --skip-tests flag can bypass that test phase; Git auto-deploys do not expose 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. Activate a previous successful deployment 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 the agent defines a persistent session key. Conversation history remains available across requests, restarts, and redeployments until its optional inactivity TTL expires or the session is deleted.