Skip to main content
Connic

Build and run AI agents on a European, code-first platform.

Engineering teams keep the agent definition, Python tools, and tests in Git. Connic deploys that repository to a managed EU runtime, with scaling, connectors, traces, storage, approvals, and governance built in.

Build your first agent
Pipeline
  1. Build imagedone
  2. Run testsdone
    1/1 · 100%
    order-support::looks_up_an_order
    1/1
  3. Deploy to productiondone
The test defined in tests/order-support.yaml runs before the production environment changes.

What is a code-first AI agent platform?

Keep agent definitions, tools, and tests in Git. Connic deploys and operates them.

What is a code-first AI agent platform?
FeatureFramework + assembled stackConnic
Agent sourceFramework-specific PythonYAML + ordinary Python
Multi-agent orchestrationConfigure it in your applicationSequential and delegated agents
DeploymentYour CI/CD and runtimeGit- or CLI-triggered deployment
Tests before releaseYour release gateTests run in the deploy pipeline
Production operationsYour operations stackManaged execution and observability
EU operating boundaryDepends on selected servicesEU Project region; EU inference for connic/* models
Source-controlled releases

Ship the agent from its repository

The mapped branch contains the agent YAML, Python tools, and release tests. Connic builds that commit and deploys it only after the tests pass.

agents/order-support.yaml
version: "1.0"

name: order-support
type: llm
model: connic/glm-5.2
description: "Resolve order questions and delegate refunds"

system_prompt: |
  Help customers understand an order.
  Look up the order before answering.
  Delegate refund requests to the refund agent.

tools:
  - orders.lookup
  - trigger_agent

guardrails:
  input:
    - type: prompt_injection
      mode: block
tools/orders.py
import os

import httpx


async def lookup(order_id: str) -> dict:
    """Return the current status of one order."""
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"{os.environ['ORDERS_API_URL']}/orders/{order_id}",
            headers={"Authorization": f"Bearer {os.environ['ORDERS_API_KEY']}"},
        )
        response.raise_for_status()
        return response.json()
tests/order-support.yaml
version: "1.0"

tests:
  - name: looks_up_an_order
    payload: '{"message":"Where is order A-1042?"}'
    expected_result: status == "completed"
    expected_tool_calls:
      - orders.lookup: invocations >= 1
Mapped release
main → production

A push starts a deployment-gated release

Connic builds the commit, runs tests/order-support.yaml, and deploys the image after the suite passes. Non-Git Projects can deploy from the CLI.

After deployment, each execution is available as a run and trace with tool calls, latency, token use, and cost.

See how deployment-gated tests run, follow the deployment workflow, or build the complete Python example without Kubernetes.

European operating boundary

Where Connic keeps processing in Europe, and where configuration matters

The EU boundary covers the selected Project region and connic/* managed inference. Customer-configured providers and destinations can send data beyond it.

German company and contract
Connic is based in Munich and contracts through a German entity. Procurement and legal teams can review the DPA and check the current subprocessor list.
EU platform and managed inference
Customers select an EU data region when creating a Project. Every connic/* model request runs only on EU inference capacity and fails closed if that boundary cannot be maintained.
Customer-configured services
End-to-end EU residency requires every configured model provider, tool, guardrail, judge, and external destination to stay in the EU. Check which models use managed EU inference.
Governance records and evidence
Enterprise AI Governance records controls and incidents and exports evidence for readiness work. Legal advice, final classification, and compliance certification remain outside the product. Review what AI Governance covers.

Code-first platform questions

A code-first AI agent platform keeps agent definitions, tools, and tests in source control. In Connic, YAML describes agent behavior and Python handles tools and lifecycle code. Connic deploys that repository to a managed runtime and provides the operational controls around it.

No. Connic is built for backend, AI, and platform engineering teams that work with code and Git. Agents are declared in YAML, while tools and lifecycle extensions are written in Python. The dashboard is used to configure and operate Projects, not to replace the repository with a drag-and-drop workflow canvas.

Connic is a managed AI agent deployment and orchestration platform. The Composer SDK provides its code-first authoring layer; Connic then deploys and runs those agents with testing, observability, guardrails, and Project data services built in.

Commit the agent definition, its Python tools, and the deployment tests to one repository. In a Git-connected Project, a push to the mapped branch starts deployment. Connic builds the image and runs its tests; a failed suite blocks release. Non-Git Projects can deploy with the CLI.

Yes. Sequential agents run a fixed chain in order, while the built-in trigger_agent tool lets an agent delegate work to another agent in the same Project. trigger_agent_at schedules delegated work for a later time. Each child execution remains visible in the run trace.

Connic is based in Munich, Projects can use an EU region, and connic/* requests run on EU inference capacity. End-to-end residency still depends on the configured providers, custom code, and external destinations.

No. Connic Enterprise AI Governance records controls and incidents and exports evidence for readiness work. Legal advice, final classification, and compliance certification remain outside the product.