The generic-HTTP approach, and why it fits agents
An agent is, at its core, a loop that talks to a model and to tools. Provider SDKs differ in their method names and response shapes, but the conceptual events — 'I sent this prompt', 'the model replied with this', 'I called this tool with these arguments', 'it returned this' — are identical across OpenAI and Anthropic. Observability that hooks those conceptual events, rather than a specific SDK, captures everything you need without caring which provider produced it.
Generic HTTP log ingestion is how you do that without coupling. Your agent already controls the moment it calls the model and the moment it calls a tool; at each of those moments you POST a small structured payload describing the step. There's no agent on your side to install, no framework to adopt — just an HTTP request you fire from wherever your agent already runs. That's why this approach works for any language and any framework: if it can make an HTTP call, it can be observed.
What each log entry should contain
Keep the payload structured and consistent so the runs assemble cleanly. Every entry carries a run ID (so all steps of one execution group together), a sequence number or timestamp (so they order correctly), and a step type (model call or tool call). For a model call, include the prompt sent and the reply received, including any tool call the model requested. For a tool call, include the tool name, its arguments, and its result.
That's enough to reconstruct the full execution path. You can add token counts or latency if you want to watch cost and speed, but the spine is the ordered prompts, replies, and tool calls. Once those land at the endpoint, agentis condenses them into a readable snapshot per run — and from there you can read the path, spot where a run diverged, and ask an LLM to debug a run when the trail is long.
how it works
- 01
Register your agent
Create the agent in agentis so it has a home for its runs. This gives you something to attach logs to and view snapshots against, whether the agent runs on OpenAI, Anthropic, or both.
- 02
Get an API key
Generate an API key for the agent. Your code will send it with each request so agentis knows which agent the logs belong to. Keep it in an environment variable, not in source.
- 03
Tag each run with a run ID
At the start of an agent run, mint a unique run ID. Carry it through the run so every model call and tool call you log can be stamped with it — this is what groups the steps into one path.
- 04
POST a structured log per step
At each model call and tool call, POST a structured entry (run ID, sequence, step type, plus prompt/reply or tool name/arguments/result) to the single ingestion endpoint with your API key. Same call shape whether the model is OpenAI or Anthropic.
- 05
View the runs as snapshots
Open agentis and read each run as an assembled snapshot — the ordered execution path. From there you debug by reading the path, and can ask the built-in LLM to flag the likely failing step on long runs.
frequently asked
Does this work the same for OpenAI and Anthropic agents?
Yes. You're capturing the universal events — prompts, model replies, tool calls, and results — not hooking into a provider's SDK. The HTTP payload you post looks the same regardless of which model produced the reply, so the same setup covers an OpenAI agent, an Anthropic agent, or an agent that uses both.
Do I have to install an SDK or agent on my side?
No. The generic-HTTP approach means you just POST a structured payload to one endpoint from wherever your agent already runs. There's nothing to install and no framework to adopt — if your code can make an HTTP request, it can send observability data. That's what keeps it language- and framework-agnostic.
What's the minimum I need to log per step?
A run ID to group the steps, a sequence number or timestamp to order them, and a step type. For model calls, the prompt and the reply (including any requested tool call); for tool calls, the tool name, arguments, and result. That's enough to assemble a readable execution path. Token counts and latency are useful optional additions.
Will adding observability slow my agent down?
It shouldn't meaningfully. Each log is a small HTTP POST you can fire alongside your existing model and tool calls, and you can send them without blocking the agent's main work. The capture is lightweight by design — the goal is to record the path, not to sit in the critical path of the agent's decisions.
Last updated June 19, 2026