Connecting your first agent

Most customers start with one AI agent in scope, see the audit report come together, and then expand. This article walks through the connect step end-to-end so you can get an agent into Kommit's scope in 15–30 minutes.

What "connected" means

In Kommit, a connected agent is one whose runtime emits events that Kommit ingests, and whose configuration is reflected in the Kommit dashboard. The agent itself still runs in your infrastructure or your LLM provider's. Kommit doesn't host the agent's execution.

Three connection modes

Mode	What it does	When to use
Log ingestion	Kommit reads agent logs from a source you point it at (S3-compatible bucket, Datadog log forwarder, Loki).	You already log everything the agent does; you want minimum-friction governance on top of that.
SDK ingestion	Your agent code calls `kommit.recordEvent(...)` at key decision points.	You want richer events than logs typically capture (decision context, retrieved chunks, policy outcomes).
Webhook ingestion	Your orchestration platform (LangSmith, Helicone, etc.) posts events to a Kommit webhook URL.	You're already on a platform that has a webhook out.

You can mix modes per agent. Most production setups use SDK ingestion for the agent's own decisions plus log ingestion as a belt-and-suspenders backup.

Step-by-step (SDK ingestion)

—Create the agent in Kommit. Settings → Agents → New. Give it a name, an environment (production / staging / dev), and a primary owner (a Kommit user who's accountable for it).
—Generate an ingestion key. The new-agent flow gives you a single-use ingestion key. Treat it like a production secret — put it in your secret manager, never commit it.
—
Install the SDK. We publish @kommit/sdk on npm and kommit on PyPI.
```
pnpm add @kommit/sdk
# or: pip install kommit
```

—Initialise the SDK in your agent runtime.

import { Kommit } from "@kommit/sdk";
const kommit = new Kommit({
  agentId: process.env.KOMMIT_AGENT_ID,
  apiKey: process.env.KOMMIT_INGESTION_KEY,
});

—
Record events at decision points. At minimum: agent run start, tool call, agent run finish. Optionally: each LLM call's input/output if you want chunk-level evidence.
```
await kommit.recordEvent({
  type: "tool_call",
  name: "send_email",
  args: { to, subject },
  policyHint: "tool.send_email",
});
```
—Verify ingestion in the dashboard. Within ~30 seconds you should see events landing under the agent's Events tab. If nothing arrives, check the agent's logs for SDK warnings — the SDK fails open and logs failures rather than blocking the agent.

Step-by-step (log ingestion)

If you'd rather not modify agent code:

—Create the agent in Kommit (same as step 1 above).
—Point Kommit at your log source. We support S3-compatible buckets, Datadog log forwarders, and Loki today.
—Define an event parser. Kommit ships parsers for the common agent frameworks (LangChain, LangGraph, Autogen, Crew, raw OpenAI / Anthropic SDK call sites). If your agent uses something custom, you can write a parser in the dashboard and Kommit applies it to incoming logs.
—Verify ingestion. Same as SDK mode — events appear within ~30 seconds.

Common pitfalls

—Don't log PII you don't need. Kommit doesn't strip PII from incoming events; what you send is what we store. Configure the SDK / your log forwarder to redact at source.
—Don't share the ingestion key across agents. One agent = one key. Sharing keys hides which agent did what at the ingestion layer, which is the entire point of having governance.
—Don't expect Kommit to control the agent in v1. Today Kommit ingests events and applies policies. It does not push back to the agent's runtime to abort a tool call. Policy enforcement is advisory (logged + alertable) in v1; full inline enforcement is on the design-partner roadmap.

See also [#supported-ingestion-sources] for the full provider list.