Logs to Behaviors

Behavior maps are generated from the production evidence you send to Adaline. For most AI applications, there is no separate Behavior-specific payload to build: send useful log traces and spans, confirm they are arriving in the right project, and Adaline can begin identifying repeated user, assistant, tool, and agent patterns. Use this page if you are mainly interested in Behaviors and want to understand which logging path to start with. For the full setup flow, see Integrate your AI Agent or the Instrument overview.

​

How logs become Behaviors

Adaline looks for repeated patterns across the traces, spans, content, outcomes, and metadata in your project. A few logs are enough to check that instrumentation works, but Behavior maps become useful after Adaline has enough examples to compare. As a rule of thumb, expect Behaviors to appear after roughly 100 logs and about 15-20 minutes of analysis time. More traffic usually gives Adaline a clearer view of repeated patterns, issue tags, and representative evidence. When analysis is ready, the Behaviors catalog should start showing row labels, short summaries, roles, issue tags when Adaline detects a likely problem, conversation or member counts, and links back to related objects. If those rows feel too generic, the fix is usually better logging: clearer trace names, named spans, outcomes, and safe metadata that separates workflows. If Behaviors do not appear, first check that Monitor shows recent traces in the same project. Then confirm the logs have readable trace and span names, useful input/output content or safe summaries, status, and enough metadata to tell workflows apart.

​

Choose an integration path

Start with the path that matches your existing stack. You can begin with broad logging and add more detailed spans later as your team learns which evidence is most useful.

​

What helps Adaline understand patterns

Useful Behavior evidence is usually the same evidence that makes Monitor and Logs readable:

• Trace names that describe the workflow or request.
• Span names for model calls, tool calls, retrieval, backend steps, or custom workflow steps.
• Input and output content, or safe summaries when full content should not be stored.
• Status or outcome, such as success, failed, partial, escalated, or user-reported issue.
• Model, provider, latency, token, and cost details where available.
• Tool and retrieval arguments, result status, timing, and safe result summaries.
• Metadata for environment, release, route, prompt, agent, experiment, or customer-safe segment.

You do not need perfect instrumentation before using Behaviors. Start with the evidence you already have, then improve trace names, span coverage, status, and metadata when the Behavior catalog is hard to interpret.

​

Coding-agent logs

Coding-agent projects can benefit from extra structure because the work often spans planning, file inspection, edits, tool calls, tests, recovery, and handoff. If you are sending logs from OpenCode or a similar coding agent, your project may need coding-agent enablement or a specific tag/metadata convention before those patterns appear in the coding-agent views. If you are unsure which metadata applies, contact support@adaline.ai. After the project is configured, use Coding-agent Behaviors and Trajectories to review task patterns and source evidence.