Fixes #28

Context

This issue is one finding from a hands-on evaluation (a Critical User Journey run) of building, tracing, and improving an agent that runs off Databricks. The agent is a LangGraph rebuild of a customer-notes workflow. It runs on a laptop and calls the Databricks Foundation Model API endpoint databricks-claude-opus-4-8. Its MLflow traces are written to Unity Catalog.

Full writeup:

• Summary: https://databricks.atlassian.net/wiki/spaces/~7120200d4c393f21a14d67bba42ffb3e92a69f/pages/6623789187
• Walkthrough: https://databricks.atlassian.net/wiki/spaces/~7120200d4c393f21a14d67bba42ffb3e92a69f/pages/6624084274

Environment

• MLflow 3.14.0, LangGraph 1.2.7, LangChain 1.3.11, databricks-langchain 0.17.0, databricks-sdk 0.94.0, openai 2.24.0, Python 3.12.
• Databricks workspace: logfood (adb-2548836972759138). SQL warehouse 79415a9aea7a3a7e.
• MLflow experiment: customer-notes-agent-uc (id 2824204872263693).
• UC trace location: catalog home_adam_gurary, schema personal_agents, table prefix customer_notes.
• Per run: roughly 1.6M input tokens across about 14 to 16 LLM calls.

Instrumentation skill should capture full span content, not a size count

Summary

When a coding agent (Claude Code) used the MLflow instrumentation skills to add tracing, it recorded only a size count in each research span (for example matches: 20 or chars: N) instead of the retrieved content itself. That left the traces with nothing to debug from. The trace store accepts large attributes, so the truncation was unnecessary and actively harmful to the analysis that followed.

Steps to reproduce

1. Ask a coding agent to instrument a multi-step agent with MLflow tracing using the skills.
2. Let it wrap retrieval or research steps that return sizable content (search hits, documents).
3. Inspect the resulting spans.

Actual behavior

Research spans recorded only a count where the retrieved text belonged. Example span output:

matches: 20

The actual retrieved content (Slack messages, documents) was not recorded, so the spans could not be used to see what the agent actually retrieved.

Root cause

The skill guidance led the agent to record a conservative size summary rather than the full content, apparently out of a concern about attribute size limits. A direct test showed that concern is unfounded: the UC OTel span attribute store accepted single string attributes of 50K, 200K, and 500K characters and read them back with full fidelity.

Expected behavior and proposed fix

The MLflow instrumentation skills should teach the coding agent to record full span inputs and outputs by default, never a bare size count where content belongs. The skill should state that the trace store accepts large attributes, so capturing complete content is the default and truncation must be a deliberate, documented exception.

Evidence and references

Fixed in the agent repo by removing all size caps and capturing full content (commit 21cea8d49). See the walkthrough linked above.