Trying to get a simple two-step task chain to work. The second agent is supposed to parse the output from the first, but it just gets garbage. It's like the framework is mangling the data between steps.
Here's the gist of the setup:
```python
task1 = Task(
description="Analyze this log line: 'ERROR: Database connection timeout'",
agent=analyst_agent,
expected_output="A structured JSON with keys 'error_type' and 'possible_cause'"
)
task2 = Task(
description="Take the analysis and suggest a fix.",
agent=sre_agent,
context=[task1]
)
```
The SRE agent receives something like `{'output': '{"error_type":...` as a string literal instead of a dict. So it tries to parse a string that's already JSON, and everything falls apart. Manually parsing the output in the second agent's instructions feels like a hack, not a feature.
Is this just how it works, or is there a proper fix? Expected a basic thing like passing data between tasks to be solved by now.
If it ain't broke, don't 'upgrade' it.
Yeah, that's a classic friction point in these chains. It's not exactly broken, but the default serialization between tasks often dumps everything, including metadata, into a string context. So you're right, you get that nested JSON string inside another structure.
The cleaner fix isn't in the second agent's instructions. You need to explicitly pull the *actual* output from the first task's result object in the second task's description. Something like:
Task(
description="Take the analysis from {task1.output} and suggest a fix.",
agent=sre_agent,
context=[task1]
)
Depending on your framework, the property might be `.result` or `.raw_output`, but the pattern's the same. It bypasses the wrapper. I've had to bake this into our internal task templates, because expecting the context list to "just work" leads to exactly the string-parsing hell you're in.
It's one of those things that feels like a hack until you realize everyone's doing it. 😅
Implementation is 80% process, 20% tool.
You've hit on the fundamental impedance mismatch between structured data and the default string-based context passing. While the workaround using `{task1.output}` can help, it's still a workaround for a design flaw.
I've found this forces you into a specific pattern: your first task's `expected_output` should be a plain language description, not a JSON spec. That way, the string that gets passed is the natural language analysis, which the second agent can actually consume. If you need structured data, you have to treat the first output as a final product, not an intermediate one.
This often means rethinking the agent chain. Can the SRE agent perform the analysis itself, guided by the first agent's reasoning?
Your bill is too high.