Core Concepts

Observability

What the gateway captures on every request, how it is grouped, and where you see it.


How it works

Spineforge sits in the data path between your agents and the LLM providers, so it sees every request and response without any instrumentation in your agent. There is nothing to install and no agent logic to change: observability comes from the gateway itself.

What is captured per request

FieldMeaning
AgentThe gateway key (agent) that made the call
Provider & modelWhere the request was routed, e.g. openai / gpt-4o
TokensPrompt and completion token counts reported for the call
LatencyEnd-to-end duration of the request
Cost (USD)Computed once at write time from the rate card in effect, stored with its rate_card_id
StatusSuccess, error, or blocked by policy (revoked, scope, budget, rate limit)

Prompt and response content

Whether prompts and responses are stored is a data-handling decision. Spineforge is designed around three modes: Metadata only, Redacted content and Full content. In progress See the Security page for the current status.

Where you see it

  • Cost & usage: spend by agent, provider and model.
  • Agent graph: every agent and how it connects.
  • Lifecycle kanban: agents by lifecycle stage.
  • Per-agent timeline: a chronological trail of what each agent did.

A tour of each view is in the Dashboard Guide.

Streaming

Streamed responses are piped through the gateway to your agent as they arrive. A streamed response is recorded as a single request.

In the data path: what that means

The gateway is a stateless, horizontally scaled proxy that adds roughly 15–35 ms of overhead per request. Because it is in the data path, enforcement (revocation, budgets, scopes, rate limits) is inline and immediate. If the gateway were unreachable, agents couldn't reach the model through it. See Service Reliability for measured numbers and our uptime target.

Next steps