AI agents are becoming increasingly capable.
They can call tools, interact with APIs, retrieve information, execute multi-step workflows, delegate tasks to other agents, and make decisions with limited human intervention.
But there is a problem.
Once an AI agent starts doing real work, simply logging the final response is not enough.
You need to know:
- What did the agent actually do?
- Which LLM calls did it make?
- Which tools did it invoke?
- How much did the run cost?
- Where did latency come from?
- Did it expose PII or secrets?
- Was there a prompt injection?
- Did a tool call perform an unsafe action?
- Did a new model or prompt version make the agent worse?
- Can you reproduce and debug the entire execution?
This is the problem we are building Splyntra to solve.
What is Splyntra?
Splyntra is an observability and security platform for AI agents.
The core idea is simple:
Observe what your agents did and understand whether it was safe — in the same execution trace.
Traditional application monitoring was primarily designed around request → response systems.
AI agents are different.
A single agent execution can look more like:
User Request
│
▼
Agent
│
├──► LLM Call
│
├──► Tool Call
│ │
│ └──► Database
│
├──► Retrieval
│
├──► Another LLM Call
│
└──► Final Response
Every step introduces new observability and security concerns.
Splyntra treats the agent run as the first-class unit of observability and attaches performance, cost, and security signals to the individual spans inside that run. (Splyntra)
One trace. Multiple signals.
One of the ideas behind Splyntra is that observability and security shouldn't have to live in completely separate systems.
The same trace that tells you:
Agent → LLM → Tool → Database → Response
can also tell you:
Latency
Token Usage
Cost
PII Detected
Secret Detected
Prompt Injection
Tool Risk
Policy Violation
Splyntra combines these signals into a unified view.
For example, instead of seeing:
"Agent execution failed."
you can investigate:
Agent Run
│
├── LLM Call
│ ├── 2,431 tokens
│ ├── $0.012
│ └── 420ms
│
├── Tool: crm.read
│ ├── 180ms
│ └── PII detected
│
└── Tool: refund.execute
├── 95ms
└── Risk: HIGH
This makes debugging agent behavior significantly more actionable.
Built on OpenTelemetry
Splyntra is OpenTelemetry-native.
That means you don't have to adopt a completely proprietary telemetry format just to understand your AI agents.
If you're already producing OpenTelemetry data, Splyntra can ingest OTLP directly and work with GenAI-related telemetry such as model names and token information. (Splyntra)
The architecture is intentionally straightforward:
AI Agent
│
▼
OpenTelemetry / Splyntra SDK
│
▼
OTLP Collector
│
├── Traces
├── Logs
├── Metrics
├── Security Signals
└── Evaluation Data
│
▼
Splyntra
│
▼
Dashboard
The goal is to avoid creating another isolated telemetry ecosystem.
Five pillars
Splyntra is built around five major capabilities.
1. Observability
Understand exactly what happened during an agent execution.
You can capture:
- Agent execution traces
- LLM calls
- Tool calls
- Retrieval operations
- Agent handoffs
- Latency
- Token usage
- Cost
- Structured logs
- Metrics
- Agent replay
This gives developers a complete execution timeline instead of just the final output. (GitHub)
2. Security
AI agents introduce a new security surface.
A prompt can contain malicious instructions.
A tool can expose sensitive information.
An LLM response can accidentally contain secrets.
Splyntra provides detection for areas including:
- PII
- Secrets
- Prompt injection
- Content moderation
- Unsafe tool calls
These signals can contribute to a unified risk score for an agent execution. (Splyntra)
The objective is to move security closer to the actual agent execution rather than treating it as something completely separate.
3. Evaluation
Observability tells you what happened.
Evaluation helps answer:
Was it good?
Splyntra supports evaluation workflows around datasets, scorers, regression detection, benchmarks, and CI gating.
For example:
Pull Request
│
▼
Run Agent Evaluation
│
├── Accuracy
├── Tool Calls
├── Latency
├── Cost
└── Regression
│
▼
CI Gate
This allows agent behavior to become part of the engineering lifecycle rather than something manually tested after deployment. (GitHub)
4. Governance
As agents become more autonomous, the question changes from:
"Can this agent call the API?"
to:
"Should this agent be allowed to call the API under these conditions?"
Splyntra's governance capabilities include concepts such as:
- Activity ledger
- Delegation
- Spend limits
- Approval workflows
- Policy enforcement
- RBAC / ABAC / ReBAC
These capabilities are particularly important for enterprise agent deployments. (GitHub)
5. Agent Identity
Agents increasingly behave like software principals.
They may need:
- Credentials
- Scoped permissions
- Delegated access
- Trust relationships
- Cross-agent communication
Splyntra includes an agent identity layer designed around these requirements. (Splyntra)
Instrumenting a Python agent
Getting started with Python is intentionally lightweight.
Install the SDK:
pip install splyntra
Then instrument your agent:
from splyntra import Splyntra, trace_agent, trace_tool, trace_llm
splyntra = Splyntra(
api_key="YOUR_API_KEY",
project="my-project",
)
@trace_agent(name="support_agent", workflow="refund")
def run_agent(query: str):
plan = call_llm(query)
result = execute_tool(plan)
return result
@trace_llm(model="gpt-4o", provider="openai")
def call_llm(prompt: str):
# Your LLM implementation
...
@trace_tool(name="crm.read")
def execute_tool(action: dict):
# Your tool implementation
...
Run your agent and you can inspect the resulting execution trace in Splyntra.
The Python SDK also supports instrumentation approaches for supported frameworks. (GitHub)
You can find the Python package here:
TypeScript / JavaScript
For JavaScript and TypeScript applications:
npm install @splyntra/sdk
You can wrap your existing agent, LLM calls, and tools without having to rewrite your architecture:
import {
Splyntra,
wrapAgent,
wrapTool,
wrapLLM,
} from "@splyntra/sdk";
new Splyntra({
apiKey: process.env.SPLYNTRA_API_KEY,
project: "my-project",
instrument: ["openai", "langgraph"],
});
const callLLM = wrapLLM(
async (prompt: string) => {
// Your LLM call
},
"gpt-4o",
"openai"
);
const readCRM = wrapTool(
async (id: string) => {
// Your tool call
},
"crm.read"
);
const runAgent = wrapAgent(
async (query: string) => {
return callLLM(query);
},
"support_agent",
"refund"
);
await runAgent("Refund my order");
The TypeScript SDK also provides decorators and a CLI for evaluation workflows and CI gating. (GitHub)
Splyntra TypeScript SDK on npm
Framework integrations
Agent infrastructure is fragmented.
Teams are building agents with different frameworks and orchestration systems.
Splyntra is designed to work across that ecosystem.
Current integrations include:
- OpenAI
- Anthropic
- Ollama
- LangGraph
- OpenAI Agents
- CrewAI
- MCP
- LlamaIndex
- Chroma
- Google ADK
- Pydantic AI
- Dify
- n8n
The goal isn't to force teams to rebuild their agents.
It's to provide a common observability and security layer underneath them. (GitHub)
Self-host it
Splyntra is designed with a self-host-first approach.
You can start the complete local stack with:
git clone https://github.com/splyntra/splyntra.git
cd splyntra
docker compose up -d
The local environment includes the dashboard, collector, detectors, evaluation components, and infrastructure. (GitHub)
The architecture uses familiar infrastructure rather than trying to reinvent the database or telemetry layer.
The core stack includes:
- Go
- OpenTelemetry
- ClickHouse
- PostgreSQL
- Docker
- Kubernetes / Helm
This keeps the infrastructure relatively boring while allowing the product layer to focus on agent-specific problems. (GitHub)
Open source and open core
Splyntra follows an open-core model.
The community edition provides the source-available core with capabilities including:
- OpenTelemetry collector
- Tracing
- Logs
- Metrics
- Cost analytics
- Detection
- Evaluation
- Dashboard
The client SDKs and integrations are Apache-2.0 licensed, while some governance, identity, SSO, control-plane, billing, and advanced capabilities are part of the commercial offering. (GitHub)
You can explore the implementation directly on GitHub:
Why we are building this
The next generation of software won't just contain APIs and microservices.
It will contain agents.
Agents that:
- Browse the web
- Query databases
- Execute transactions
- Write code
- Call APIs
- Communicate with other agents
- Access enterprise systems
- Make decisions
That changes the observability problem.
For traditional applications, you might ask:
"Why did this request fail?"
For agentic systems, you increasingly need to ask:
"Why did the agent make this decision?"
"Which tools did it use?"
"What information influenced it?"
"How much did the execution cost?"
"Was the action safe?"
"Can I reproduce the behavior?"
"Did the latest model change introduce a regression?"
These are not separate questions.
They are different dimensions of the same agent execution.
That's the problem space Splyntra is targeting.
Try it yourself
If you're building AI agents, we'd love for you to try Splyntra and tell us what you think.
GitHub: github.com/splyntra/splyntra
Documentation: splyntra.com/docs
Python SDK: PyPI – splyntra
TypeScript / JavaScript SDK: npm – @splyntra/sdk
If you're working on agent infrastructure, security, evaluation, or observability, we'd especially love feedback on the architecture and the developer experience.
⭐ Star the repository if you find it useful, open an issue if you find something broken, and contribute if you'd like to help shape the future of agent observability.
Splyntra — Observe. Evaluate. Secure. Govern. Trust.
Top comments (1)
Agent observability gets interesting when it explains the decision path, not just the event log. Security and debugging need the same timeline if you want incidents to be reconstructable.