What Is an Attribute?

What Is an Attribute?

An attribute, in an AI/ML context, is a named property associated with a data record, a model output, or an observability span. In tabular machine learning, attributes are the columns of a dataset — features that serve as model inputs. In LLM observability, attributes are key-value pairs attached to OpenTelemetry spans, such as llm.model.name, llm.token_count.prompt, or agent.trajectory.step. The shared idea is a structured property that carries meaning about an object. In FutureAGI, attributes are how every trace, dataset row, and evaluator output stays queryable, sliceable, and joinable.

Why attributes matter in production LLM and agent systems

Attributes are the difference between an observability stack you can debug and one you can’t. A trace without attributes is a string of spans you have to read top to bottom; a trace with the right attributes lets you ask, “show me all agent traces in the last 24 hours where the model was gpt-4o-mini, the route was cost-optimized, and eval.task_completion < 0.5.” That query is impossible without attributes attached at instrumentation time.

The pain shows up at debug time. An SRE chasing a quality regression has to scroll through thousands of traces because nothing is indexed. A platform engineer cannot tell whether the failures are concentrated in one region, one route, or one model variant — the attributes that would slice that view weren’t emitted. A compliance lead is asked which user cohort hit a specific guardrail and has no way to filter — the cohort attribute was missing.

In 2026 multi-step agent stacks, attribute discipline matters more, not less. A single user request fans out into a planner, a retriever, and several tool calls. Each of those spans needs canonical attributes — agent.trajectory.step, tool name, model name, evaluator score — for trajectory-level analysis to work. Without attribute consistency, an agent trace is a flat list of LLM calls with no idea what step did what.

Attributes are not metrics by themselves. BLEU, exact match, and p99 latency report outcomes; attributes explain which model, route, cohort, or agent step produced those outcomes. That contrast matters when a dashboard shows a failure-rate spike. The question is not only whether quality dropped; it is which attributes isolate the slice that changed.

How FutureAGI handles attributes

FutureAGI’s approach is to make attribute emission canonical at instrumentation time, not at query time. At trace level, traceAI integrations such as traceAI-openai, traceAI-langchain, and traceAI-openai-agents emit a standard set of OpenTelemetry attributes on every span: llm.model.name, llm.model.provider, llm.token_count.prompt, llm.token_count.completion, agent.trajectory.step, plus framework-specific attributes for tool name and handoff target. At evaluation level, every fi.evals evaluator result writes attributes back onto the originating span — eval.groundedness.score, eval.task_completion.score — so the dashboard can slice by either span attributes or evaluator attributes interchangeably. At dataset level, Dataset rows carry user-defined attribute columns (cohort, route, version) that flow through evaluation, so the dataset-level attribute and the trace-level attribute share the same vocabulary.

Concretely: an engineering team shipping an agent on traceAI-openai-agents filters their FutureAGI dashboard by llm.model.name = "gpt-4o-mini" AND agent.trajectory.step = "planner" AND eval.tool_selection_accuracy.score < 0.7. The view returns the exact slice — every planner span where the cheaper model picked the wrong tool — and the team patches the routing rule in the Agent Command Center. Without those attributes, the team would have nothing to slice on.

How to measure attributes in production

Canonical attributes worth standardizing on for production:

• llm.model.name + llm.model.provider: model-level slicing, essential for any dashboard.
• llm.token_count.prompt + llm.token_count.completion: cost attribution and context-pressure analysis.
• agent.trajectory.step: step-level slicing on agent traces; the canonical OTel attribute for trajectory analysis.
• session.id + user.id: cohort-level slicing for user-impact analysis.
• eval.<evaluator_name>.score: evaluator scores written back onto spans so quality slices; TaskCompletion returns whether an agent completed the requested task.
• gateway.route + gateway.guardrail.decision: gateway-level slicing for routing and guardrail debugging.
• Attribute coverage rate: percentage of production spans with required keys present; alert when coverage drops below the team’s instrumentation threshold.

Minimal Python:

from fi.evals import TaskCompletion
# traceAI auto-emits canonical attributes on instrumented frameworks.
# Custom attributes can be added per call via the OTel span context.

result = TaskCompletion().evaluate(
    input=user_request, trajectory=trace_spans
)
# Result writes eval.task_completion.score back onto the parent span
print(result.score, result.reason)

Common mistakes

• Inconsistent attribute names across services. Two services emitting model_name and llm.model.name split dashboards; pick one canonical schema and enforce it in instrumentation review.
• Missing cohort attributes. Without user.cohort, tenant.id, or route.id, a quality regression looks global even when one audience or route is failing.
• Putting variable-length text in attributes. Attribute values should be short, low-cardinality keys; prompts, documents, and long tool outputs belong in span events or external logs.
• Forgetting attributes on tool spans. Agent trajectories need attributes on tool calls, retriever spans, and handoffs, not just the parent LLM call.
• Skipping evaluator-score attributes. Without eval.<name>.score written back to spans, engineers cannot filter traces by failure severity or compare releases by quality slice.