DEV Community: Anil Murty

What is OpenTelemetry, and why does it matter for AI agents?

Anil Murty — Mon, 11 May 2026 19:59:10 +0000

This post originally appeared on tokenjam.dev/blog. It's part of a 14-post series on the agentic AI ecosystem.

TL;DR

OpenTelemetry is the CNCF standard for vendor-neutral observability instrumentation. Write once, export anywhere.

Three core components: SDKs (in your code), OTLP (the wire protocol), and collectors/backends (where data lives).

The GenAI semantic conventions define a shared schema for LLM traces: gen_ai.request.model, gen_ai.usage.input_tokens, and others. They're actively evolving but already widely adopted.

Claude Code natively emits OTLP traces with CLAUDE_CODE_ENABLE_TELEMETRY=1; agent frameworks like LangChain, LlamaIndex, and others follow the same pattern.

Lock-in is the real problem OTel solves. Instrument once, and any OTel-aware backend can consume your traces without re-architecting.

What is OpenTelemetry?

OpenTelemetry is the Cloud Native Computing Foundation's standard for collecting and exporting observability signals (traces, metrics, and logs) from applications. Instead of locking you into a single vendor's telemetry format, OpenTelemetry defines how applications emit telemetry data in a vendor-neutral way, using the OpenTelemetry Protocol (OTLP). You instrument your code once and can send your telemetry to any compatible backend: Datadog, New Relic, Grafana, Jaeger, or any other system that speaks OTLP.

The three components: SDKs, OTLP, and backends

Three moving parts.

1. SDKs (instrumentation in your code)

An OpenTelemetry SDK is a library that runs in your application. It collects traces, metrics, and logs from your code and hands them off for export. You install it, configure it, and call its APIs (or rely on auto-instrumentation) to emit telemetry. For Python agents, the OpenTelemetry Python SDK is the foundation. For TypeScript, OpenTelemetry JavaScript serves the same purpose.

SDKs do the heavy lifting. They manage span lifecycle, batch telemetry, apply sampling policies, and handle backpressure when backends are slow. Different instrumentation libraries (for LangChain, Anthropic, Ollama, and others) sit on top of an SDK and emit standardized spans into it.

2. OTLP: the wire protocol

OTLP (OpenTelemetry Protocol) is how telemetry gets from your SDK to a backend. OTLP runs over gRPC or HTTP/1.1, uses Protocol Buffers for encoding, and specifies backpressure handling and retry semantics. You don't think about OTLP directly. It's configured via environment variables like OTEL_EXPORTER_OTLP_ENDPOINT and OTEL_EXPORTER_OTLP_HEADERS. It's the contract between your SDK and any backend that claims OpenTelemetry support.

3. Collectors and backends

An OpenTelemetry collector is a standalone service that receives telemetry data via OTLP and routes it to backends, applies transformations, and handles batching at scale. A backend (Datadog, Grafana Loki, Jaeger, Honeycomb, and others) stores and queries your traces. You can skip the collector for small workloads. Many apps export directly to a cloud backend via OTLP. Collectors give you flexibility: they let you filter and enrich telemetry before it hits your backend, and they buffer data when backends are slow.

Why agents need OpenTelemetry specifically

Vendor lock-in is real for observability. If you instrument your agent to emit telemetry in Datadog's proprietary format, switching to New Relic means rewriting instrumentation across your codebase. For organizations with many agents and teams, this tax is enormous.

OpenTelemetry fixes this by making the instrumentation the constant, not the vendor. Your agent code emits OTLP. Your backend is the variable. You can migrate backends, or use multiple backends simultaneously, without touching your instrumentation layer.

This matters more for agent teams because agent complexity is growing. A modern agent traces LLM calls, tool invocations, retrieval steps, and agent reasoning across multiple frameworks and runtimes. A shared observability standard means you're not training teams to emit telemetry differently for each agent tool; they all follow the same conventions.

The GenAI semantic conventions

OpenTelemetry includes a specification for semantic conventions: standardized attribute names and meanings that make spans interoperable across backends. For generative AI, the OpenTelemetry GenAI semantic conventions define how to structure traces from LLM calls and agent steps.

Key attributes include:

gen_ai.system: The GenAI system or LLM provider (e.g., openai, anthropic, ollama).
gen_ai.request.model: The name of the model being invoked (e.g., claude-3-5-sonnet).
gen_ai.operation.name: The operation type (e.g., chat, completion, embedding).
gen_ai.usage.input_tokens and gen_ai.usage.output_tokens: Token counts from the LLM response.
gen_ai.response.id: The response ID from the model provider.
gen_ai.agent.id, gen_ai.agent.name, gen_ai.agent.version: Identity and version of the agent.
gen_ai.conversation.id: Unique identifier for a conversation thread (for multi-turn traces).

These conventions are actively evolving; the specification is not frozen. That's by design. As new use cases emerge (tool use, function calling, retrieval-augmented generation, multi-agent coordination), the spec grows. Tools that adopt the conventions now benefit immediately. They gain interoperability across backends even as the spec matures.

Adopting these conventions in your agent instrumentation means any OpenTelemetry-aware backend can parse and query your traces without custom parsing logic. You get consistent dashboards and analytics across vendors.

How real agent runtimes emit OTel today

OpenTelemetry adoption in the agent ecosystem is accelerating. Concrete examples:

Claude Code

Claude Code natively emits OpenTelemetry traces when you set the CLAUDE_CODE_ENABLE_TELEMETRY=1 environment variable. You then configure where traces go using standard OTEL environment variables:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_EXPORTER_OTLP_ENDPOINT=https://your-backend.example.com:4317
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc

For full configuration details, see the Claude Code environment variables documentation.

LangChain

LangChain supports OpenTelemetry instrumentation via the opentelemetry-instrumentation-langchain package. You instrument your LangChain app and export via any OTLP-compatible backend:

from opentelemetry.instrumentation.langchain import LangchainInstrumentor

LangchainInstrumentor().instrument()

Traces follow the GenAI conventions, so your LangChain chains are observable across any OpenTelemetry-aware platform.

LlamaIndex + OpenInference

LlamaIndex integrates with OpenInference, a set of conventions built on top of OpenTelemetry for AI observability. OpenInference spans are valid OTLP traces, so you get the same portability as native OpenTelemetry.

OpenLLMetry by Traceloop

OpenLLMetry is a collection of OpenTelemetry instrumentations for LLM apps. It provides ready-made instrumentation for LangChain, Anthropic, Ollama, Pinecone, Qdrant, and many other LLM-adjacent services. Because it's built on OpenTelemetry, any instrumentation you install works with any OTLP backend.

Notable tools and SDKs

The OpenTelemetry ecosystem for agents includes:

OpenTelemetry Python SDK: The core SDK for Python agents. Use this as your foundation for any Python-based agent instrumentation.
OpenTelemetry JavaScript SDK: The equivalent for Node.js and browser-based agents.
OpenLLMetry: Pre-built instrumentations for LangChain, Anthropic, OpenAI, LlamaIndex, Ollama, Qdrant, and others. Reduces boilerplate if your agent uses popular frameworks.
OpenInference by Arize: A semantic convention and instrumentation set for AI workloads. Integrates with OpenTelemetry and works with any OTel backend, including Arize Phoenix, Jaeger, and Datadog.
Phoenix by Arize: An open-source observability tool for ML and LLM apps that consumes OpenInference (and thus OpenTelemetry) traces.
Collector distributions: OpenTelemetry Collector is the standard. Vendor-specific distributions (e.g., Datadog Agent, New Relic Agent) also speak OTLP.

Common questions

Why are my LLM calls showing up as HTTP spans instead of GenAI spans?

You probably have base HTTP instrumentation without an LLM-aware layer on top. The default OpenTelemetry HTTP instrumentation captures your LLM API calls as plain HTTP spans (POST /v1/messages, 200 OK, 142ms). They show up. They're just missing the actually-useful attributes: model name, token counts, response ID. To get GenAI semantic-convention spans, install an LLM-aware instrumentor: OpenLLMetry's Anthropic or OpenAI instrumentor, OpenInference, or use a framework that emits GenAI spans natively (Claude Code, LangChain via its OTel package). Install the instrumentor (e.g., opentelemetry-instrumentation-anthropic from OpenLLMetry) and initialize it before your code creates the LLM client. After that, calls to client.messages.create() should produce gen_ai.* spans alongside the HTTP spans, and you can filter on gen_ai.system in your backend.

Which OpenTelemetry SDK should I use with my agent framework?

Depends on your language and framework. Python agents use the OpenTelemetry Python SDK. If you're on LangChain, LlamaIndex, or another framework, look for that framework's OTel instrumentation package first (via OpenLLMetry or framework-native support). If no instrumentation exists, you can hand-instrument your code using the SDK directly.

What's OTLP?

OTLP is the OpenTelemetry Protocol: the wire format and transport mechanism for sending telemetry data from your SDK to a collector or backend. It's built on Protocol Buffers and runs over gRPC or HTTP/1.1. You don't configure OTLP directly. You set environment variables like OTEL_EXPORTER_OTLP_ENDPOINT to point your SDK at a backend.

Does setting CLAUDE_CODE_ENABLE_TELEMETRY=1 send my data to Anthropic?

No. The flag tells Claude Code to emit OpenTelemetry traces to whatever OTLP endpoint you configure via OTEL_EXPORTER_OTLP_ENDPOINT. If you don't set an endpoint, the SDK has nowhere to send them and they're dropped on the floor. Anthropic doesn't receive your traces from this path. That's distinct from Anthropic's usage-and-billing telemetry, which is sent to Anthropic regardless of the OTel flag because it's how the API gets metered. The OTel data is for you: send it to Datadog, Grafana, a local Jaeger, or wherever you run observability. See the Claude Code env-vars docs for the full configuration list.

How do I set up telemetry export in my agent?

Standard pattern:

Install the OpenTelemetry SDK for your language.
Install instrumentation packages for your frameworks (LangChain, Anthropic, and so on).
Initialize the instrumentation in your agent startup code.
Set OTEL environment variables to point at your backend:
- OTEL_EXPORTER_OTLP_ENDPOINT: Your backend's OTLP endpoint.
- OTEL_EXPORTER_OTLP_PROTOCOL: grpc or http/protobuf.
- OTEL_EXPORTER_OTLP_HEADERS: Auth headers, if needed.

See your backend's documentation for the specific OTLP endpoint URL.

Can I use OpenTelemetry with multiple backends simultaneously?

Yes. Configure multiple exporters in your SDK, or use an OpenTelemetry Collector to fan telemetry out to multiple destinations. Common during a backend migration, or when you want redundancy.

What is Agent Observability?

Anil Murty — Mon, 11 May 2026 19:52:34 +0000

This post originally appeared on tokenjam.dev/blog. It's part of a 14-post series on the agentic AI ecosystem.

TL;DR

Agent observability captures what an agent did (tool calls, token costs, latency, reasoning chains) at detail sufficient to debug and audit behavior in production

Traditional logs and metrics aren't enough; you need traces that record the LLM's step-by-step decisions, tool invocations, and outcomes

Agents are harder to observe than services because of nondeterminism, deeply nested calls, prompts and completions as data, and vocabulary that didn't exist three years ago

OpenTelemetry GenAI semantic conventions are becoming the emerging standard for agent telemetry

Agent observability is the practice of capturing what an AI agent did (its tool calls, token costs, behavioral patterns, and outcomes) at a level of detail sufficient to debug, optimize, and audit agent behavior in production. You record the agent's full journey: every decision point, every tool invocation, every LLM call with inputs and outputs, latencies, costs, and errors. Service observability captures what your code did. Agent observability captures the reasoning chain itself: the sequence of thoughts and decisions that led the agent to act.

Why agent observability is harder than service observability

Service observability is built on a predictable model. A request comes in, your code executes a series of steps, a response goes out. Each step is deterministic. Logs tell you what happened. Metrics tell you how long it took and whether it succeeded.

Agents break this model.

Nondeterminism is the core problem. The same input to an agent with the same model and parameters might produce different outputs on different runs. The LLM samples from a probability distribution. You can't debug an agent from logs alone. You have to capture the complete trace of that specific run to understand what reasoning led to that specific output.

Tool calls are deeply nested. A service call stack might be five or ten levels deep. An agentic system can have an agent call a tool, which triggers a retrieval operation, which calls an embedding model, which calls a database, which triggers another tool. The nesting is deep and irregular. A trace that doesn't capture every step in this chain will miss the real bottleneck.

Prompts and completions are your actual data. In a service, your data is SQL queries and JSON payloads. In an agent, your data is the prompt sent to the LLM and the completion it returned. These are large and unstructured. They're often sensitive: they contain user context, proprietary information, internal state. Traditional logging systems don't handle this well. Observability for agents has to be built around capturing and safely storing these artifacts.

The vocabulary didn't exist three years ago. Terms like "token usage," "tool selection," "context window," and "hallucination" are specific to the agentic context. Existing APM (application performance monitoring) tools (Datadog, New Relic, Dynatrace) were built for microservices. They have no native concept of an LLM call, a token count, or a tool invocation. Shoehorning agent data into these systems works. It's also awkward.

The three pillars, adapted for agents

Observability has three pillars: traces, metrics, logs. The definitions shift when you apply them to agents.

Traces capture the complete execution path of a request. In a microservice, a trace is a sequence of function calls and RPC hops. In an agent, a trace is the agent's full journey: the user input, each LLM call (with prompt and completion), each tool invocation and result, latency at each step, token usage at each step, and the final output. A trace is the highest-fidelity record you have. It answers questions like "Why did the agent choose tool X instead of tool Y?" or "Where did the latency spike occur?"

Metrics are aggregations: counts and percentiles. In services, you track request latency, error rate, throughput. For agents, you track cost per request (sum of token usage × model pricing), latency per LLM call, tool invocation frequency, error rates (both LLM errors and tool errors), and token efficiency (useful output tokens vs. wasted context). Metrics let you spot trends over time and set up alerts when something goes wrong at scale.

Logs are raw events: "This LLM call failed," "Token limit exceeded," "Tool returned an error." In a service, logs focus on errors. In an agent, logs are also informational: "Agent selected tool X." "Retry attempt 2 of 3." Logs are lower resolution than traces. They're faster to query and more storage-efficient.

What you actually capture

A production-grade agent observability system captures:

LLM calls: Model name, parameters (temperature, max_tokens, top_p), the prompt sent, the completion received, token counts (input and output), latency, cost, success or failure. This is the core of agent observation.
Tool invocations: Tool name, input parameters, output, latency, whether the tool succeeded or failed, and any retry information. Tools are where your agent touches the outside world. They cause most of your latency and most of your errors.
Token usage per call: Not just total tokens consumed. A breakdown: how many tokens in the context window, how many in the prompt, how many in the response. This helps you optimize context and identify tokens wasted on irrelevant context.
The agent's reasoning chain: The intermediate thoughts or justifications the agent produced at each step. Some LLM frameworks (like ReAct) explicitly generate these; others encode them implicitly. Capturing this chain is what lets you debug why an agent made a particular decision.
Model and parameters: Which model was used, which version, what temperature and sampling parameters. This matters because the same agent with different parameters can behave very differently.
Errors and retries: When a tool call failed, did the agent retry? How many times? Did it eventually succeed or give up? This tells you if your agent is robust or brittle.
Latency per layer: Total latency is a sum of LLM latency + tool latency + overhead. Breaking this down tells you where to optimize.

These signals should conform to the OpenTelemetry semantic conventions for generative AI. The conventions define a standard schema for representing LLM calls, tool use, embeddings, and agent systems in trace data. Adopting the standard means your agent traces can be ingested by any OpenTelemetry-compatible backend (Jaeger, Datadog, Elastic, or a custom system) without vendor lock-in. See What is OpenTelemetry for AI agents? for a deeper dive.

Common questions

Why does my trace show 47 LLM calls when I only invoked the agent once?

Three common causes. First, the framework you're using (LangChain, LlamaIndex, AutoGen, CrewAI) might be making nested chains where each "step" is itself an LLM call: a planning call, an action call, a reflection call, a synthesis call. A single user request fans out fast. Second, retries: if a tool call returns an unexpected error or the LLM produces malformed output, many frameworks silently retry with backoff, multiplying calls. Third, agent loops: if the agent can't converge on an answer, it keeps reasoning and acting until it hits a max-iteration limit. Open the trace tree and look at timestamps. Tightly clustered calls with the same model and parameters mean retries. Spread-out calls with different prompts mean the framework is decomposing the task more than you expected.

My agent traces are 50MB each. Should I be worried?

Yes, in a specific way. Trace size is dominated by prompt and completion text. A 50MB trace means you're sending massive prompts to the LLM: huge system prompts, retrieved documents, long conversation history, included file contents. The cost is real: that's a lot of input tokens per call. The performance hit is also real because most trace UIs struggle to render or query traces above ~10MB. Two fixes work. First, reduce what you put in the prompt: tighter system prompts, smarter retrieval, summarize conversation history rather than passing it raw. Second, configure your observability tool to truncate long fields above a threshold (Langfuse, Arize Phoenix, and Datadog all support this). Truncated traces are still useful for navigation, and you can fetch the full prompt from your application logs if you actually need it.

Can I use my existing APM (Datadog, New Relic) for agents?

Partially. Datadog and New Relic have built LLM modules onto their existing platforms. They work. They weren't designed for agents from the ground up. They're better at capturing that an LLM call happened than at capturing the reasoning chain or the interaction between multiple tool calls. If you're already in Datadog, LLM Observability is a reasonable choice. If you're starting fresh, a tool built for agents will give you more signal.

What should I capture in production agent traces?

Start with: every LLM call (prompt and completion), every tool invocation (name and result), latency per call, total token usage, and final outcome (success or failure). Add error details if the agent failed. Once that's stable, add cost breakdown per model and tool selection reasoning. Don't try to capture everything on day one.

How do I avoid storing sensitive data in traces?

Most tools support redaction: marking which fields should not be logged (API keys, user PII, secrets). Some (like Datadog LLM Observability) ship with automatic PII detection. Build redaction into your SDK wrapper early; it's easier to add than to retrofit. Also consider sampling. You don't need to trace every request, just a statistically significant sample.

How much overhead does observability add?

Good observability SDKs are asynchronous. Traces are queued locally and sent in batches in the background, so they add minimal latency to your agent's response time. Expect overhead of 5–15% at the p99, depending on the tool and your stack. That's a worthwhile trade-off for production visibility.

Agents 101: Reasoning, Actions & Autonomy

Anil Murty — Mon, 11 May 2026 19:30:52 +0000

This post originally appeared on tokenjam.dev/blog. It's part of a 14-post series on the agentic AI basics and ecosystem.

TL;DR

An AI agent uses an LLM to reason about a goal and decide what actions to take, calling tools and observing results until the goal is reached

Agents differ fundamentally from chatbots (which don't act) and workflows (which don't decide)

The ReAct pattern (reasoning + acting) is the dominant architecture in modern agent systems

Agents range from copilots that suggest actions to fully autonomous systems that run unattended for hours

Key components: the LLM (reasoning), tools (actions), context/memory (state), and a control loop (orchestration)

What is an AI agent? An AI agent is a system that uses a large language model to make decisions and take actions in pursuit of a goal. It calls tools, observes what they return, and iterates until the goal is reached. A chatbot waits for the next message; an agent plans and executes its own sequence of steps.

Why it matters

The term entered the mainstream in late 2022, when projects like AutoGPT showed that LLMs could direct their own execution. The concept wasn't new. Researchers had been studying goal-directed autonomous systems for decades. What changed was accessibility: capable base models (GPT-4, Claude) and standardized tool-calling APIs made it practical to build a working agent in a few dozen lines of code.

The word now gets used loosely. Some vendors call a chatbot with a search feature an agent. Others claim that any LLM inference with retrieval is "agentic." This inflation matters. It obscures what's actually new and what's repackaging. Precision helps you know what you're building or evaluating.

Agents represent a shift in how LLMs are deployed. The old model: user asks a question, system returns an answer, conversation ends. Agents invert that. The system receives a goal, decides on sub-goals, gathers information, corrects itself, and iterates without waiting for permission between steps. New architecture. New error handling. New thinking about safety and observability.

Agents vs. chatbots vs. workflows vs. traditional AI

A quick way to distinguish these four categories is to ask: does it use an LLM to decide what to do next? And can it call tools to act on those decisions?

Chatbots use an LLM to generate text. They don't call tools, and they don't pursue goals across steps. A customer-service chatbot answers your question. It doesn't modify your account or call internal APIs unless you ask. Even then, it tends to suggest options or retrieve data rather than decide and act. The LLM's job is to understand and respond.

Workflows call tools and pursue goals. They don't use an LLM to decide which tool to call or how to interpret the result. A workflow might be: fetch customer data, run a validation rule, log an event, send an email. Each step is predefined. Branching is rule-based. The LLM is not in the loop. Workflows are predictable and cheap. They break when the task is ambiguous or open-ended.

Agents combine both. The LLM observes the current state and decides which tool to call next. It adapts and self-corrects as it goes. If a tool call fails, the agent reasons about why and tries something else. The flexibility costs you something. Agents are less predictable, more expensive per inference, and harder to debug. The reward is open-ended tasks, where the path isn't predetermined.

Traditional AI/ML systems (classifiers, regressions, recommenders) optimize a fixed function learned from data. They have no LLM, and they don't pursue multi-step goals. They are specialized and efficient. Generalizing to a new task means retraining.

The table below summarizes the differences:

Aspect	Chatbot	Workflow	Agent	Traditional ML
Uses LLM to decide next step?	No (generates text)	No (follows rules)	Yes	No
Calls tools?	Rarely; usually retrieval only	Yes; predefined sequence	Yes; chosen by LLM	No
Pursues multi-step goal?	No (responds to input)	Yes; fixed path	Yes; adaptive path	No
Handles ambiguous tasks?	Moderate (can discuss)	Poor (requires rigid structure)	Good (can reason and adapt)	Poor

The ReAct pattern and core components

Most agents built since 2023 follow a pattern called ReAct (Reasoning and Acting), introduced in Yao et al.'s 2022 paper from Google Research and Princeton. The idea is straightforward. The LLM produces reasoning steps (thinking aloud about what it needs to do) interleaved with actions (tool calls). It observes the result, then reasons further.

A ReAct loop looks like this:

Observation: The agent observes the current state (the original goal, prior tool results, conversation history).
Reasoning: The LLM thinks through the problem: "I need to fetch the user's account, check their history, then decide whether to approve the request."
Action: The agent calls a tool, say fetch_account(user_id).
Observation: The agent receives the result and feeds it back to the LLM.
Loop: The LLM reasons again, decides on the next action, and repeats until it either reaches the goal or determines that the goal isn't achievable.

The pattern works because the reasoning traces make the LLM's decisions interpretable. You can see why it chose an action. They also enable self-correction: if a tool result is unexpected, the LLM can reason about what went wrong.

An agent's core components are:

The LLM (reasoning engine): Decides what action to take based on the goal and current state. The decision-making layer.
Tools (action layer): Functions the agent can call: APIs, database queries, code execution, web searches, file operations. Tools are how the agent affects the world.
Context and memory (state): Everything the agent knows: the original goal, conversation history, prior tool results, and any persistent state it needs. Without good memory management, agents hallucinate and repeat mistakes.
Control loop (orchestration): The code that runs the loop. It calls the LLM, parses the output for tool calls, executes them, and feeds results back. Modern frameworks (Anthropic's Claude SDK, LangChain, LlamaIndex) handle this. You can also implement it from scratch.

Levels of autonomy

Agents exist on a spectrum. On one end are suggestion-based copilots that nudge you. On the other are autonomous systems that run unattended for hours.

Copilot mode (suggestion): The agent observes what you're doing and suggests the next action. You approve before it executes. Example: Cursor's autocomplete suggests the next line of code; you hit Tab to accept or Escape to reject. The model is doing some reasoning. You stay in control of execution.

Agentic mode (supervised autonomy): The agent makes and executes decisions within a scope you define. You might say "add tests for this file" and the agent writes tests, runs them, and shows you the result, all without asking permission between steps. You can pause or override at any point. Example: Claude Code in an IDE, or an agent working a bounded coding task. The agent is autonomous within the scope, not globally.

Autonomous agent (unattended): The agent pursues a goal with minimal human oversight. You set a goal ("reduce our average response time by 10%") and the agent decides what to measure, what to try, what to roll back, and what to keep. It might run for days, making changes and watching outcomes. Example: an agent managing an experimentation platform, or optimizing an ad-bidding algorithm. These are rare and tend to be domain-specific. The cost of mistakes is too high for general-purpose deployment.

Notable tools

Here are some widely used agent runtimes and frameworks, current as of 2026:

Claude Code (anthropic.com/product/claude-code): Anthropic's agentic coding tool in the terminal, IDE, and browser. Understands your codebase, executes tasks, and handles git workflows.
Cursor (cursor.com): AI code editor with agent mode. Autonomously explores your codebase, edits files, runs tests, and implements features.
OpenHands (openhands.dev): Open-source autonomous agent for software engineering. Runs in a Docker sandbox, can execute complex tasks end-to-end, and publishes pull requests.
Aider (aider.chat): Open-source AI pair programmer for the terminal. Works with your git workflow, supports multiple LLM providers, and commits changes automatically.
Continue (continue.dev): Open-source IDE extension for VS Code and JetBrains. Offers autocomplete, chat, and agent modes, works with any LLM provider.
AutoGPT (agpt.co): Open-source autonomous agent framework, released in 2023. Pioneering example of general-purpose agent architecture; known for demonstrating both promise and limitations of autonomous systems.

Common questions

How is an agent different from a chatbot?

A chatbot responds. An agent pursues. Ask a chatbot "book me a flight" and it asks clarifying questions, then waits for you to confirm. Ask an agent and it gathers options, checks your calendar, considers your budget, and books, without asking permission between steps. The chatbot reacts. The agent acts.

What's the difference between an agent and a workflow?

A workflow is a fixed sequence of steps determined in advance. You define "do A, then B, then C, with these rules for branching." A workflow always takes the same path for the same inputs. An agent reasons about which steps to take and in what order, adapting based on intermediate results. Workflows are predictable and efficient. Agents trade predictability for flexibility.

Why does my agent keep calling the same tool five times in a row?

That's a loop, and the LLM probably doesn't recognize what the tool returned as the answer it was looking for. Common causes: the tool returned an error and the agent retried with the same inputs; the response shape was different from what the LLM expected, so it kept trying; the system prompt left the goal vague enough that the LLM thrashes between candidates. Fixes that work: clearer descriptions in your tool schema, explicit error messages from the tool ("not found" rather than null), and a hard call-count budget so the loop terminates rather than burning tokens.

How autonomous do agents actually get?

Depends on the task and the risk. In low-risk domains (code suggestions, documentation), agents run nearly unsupervised. In higher-risk domains (financial transactions, customer-facing decisions), agents operate under constraints: bounded scope, human review loops, or escalation to a human when confidence is low. Most production agents are supervised autonomy, not full autonomy.

Is it normal for a single Claude Code session to cost $40?

Not normal, not rare. A long session that maintains a big context and re-reads files often will pile up tokens fast. Three places to look. First, prompt caching: is the run hitting the cache, or rebuilding the prompt every turn? Second, context bloat: huge system prompts, large repos, and many open files multiply per-call cost. Third, model choice: Opus is meaningfully pricier than Sonnet on the same workload. Set a hard spend cap and watch tokens per turn. Most overruns trace to context size, not call count.

Why do some agents get stuck or make silly mistakes?

Agents inherit their LLM's limitations. An LLM can hallucinate or misinterpret what a tool returned. Across multiple reasoning steps, these errors compound. A bad tool result leads the agent down the wrong path. Confirmation bias makes it ignore contradictory evidence. Good design mitigates the failure modes: clear tool descriptions, explicit error signals from tools, and a memory model that lets the agent backtrack rather than press on with bad state.

DEV Community: Anil Murty

What is OpenTelemetry, and why does it matter for AI agents?

What is OpenTelemetry?

The three components: SDKs, OTLP, and backends

1. SDKs (instrumentation in your code)

2. OTLP: the wire protocol

3. Collectors and backends

Why agents need OpenTelemetry specifically

The GenAI semantic conventions

How real agent runtimes emit OTel today

Claude Code

LangChain

LlamaIndex + OpenInference

OpenLLMetry by Traceloop

Notable tools and SDKs

Common questions

Further reading

What is Agent Observability?

Why agent observability is harder than service observability

The three pillars, adapted for agents

What you actually capture

Common questions

Further reading

Agents 101: Reasoning, Actions & Autonomy

Why it matters

Agents vs. chatbots vs. workflows vs. traditional AI

The ReAct pattern and core components

Levels of autonomy

Notable tools

Common questions

Further reading