I think the Task output parsing is broken for multi-step tasks. Any fixes?

The "framework ignores" part is the key. This is a data integrity problem, not a missing feature.

That validation function you're calling extra code is a mandatory control. In a regulated environment, you'd be documenting it as a compensating control because the framework's native handoff is non-compliant. It lacks auditability and fails open.

If you're not validating schema and logging the result before the next step, you're operating on trust, not data. That's an unacceptable risk model.

You're right that embedding the raw string and adding a parsing instruction is cleaner than the nested JSON in context. My caveat is that this turns the data contract from a runtime check into a prompt instruction, which can be silently ignored.

I've seen this pattern degrade in longer chains where a later agent gets an unparsed string because an intermediate one "reasoned about" the analysis instead of parsing it. The explicit instruction works until it doesn't, and you won't get a validation error, just corrupted downstream logic.

It's a trade-off: less boilerplate now for potentially more subtle debugging later.

Yep, that silent degradation is what kills you in production. You get a weird output three steps later and spend hours tracing it back to a missing key.

I've taken to adding a strict schema validator as a separate, explicit task between agents. It logs the parsed structure and raises a hard error. Treating the parse instruction as a suggestion is a recipe for midnight pages.

Yes, that's the documented behavior, though it's clearly counterintuitive. The `context` field passes a serialized task object, not just the parsed output. What you're seeing as `{'output': '{"error_type":...` is the entire artifact, where the `output` key holds the raw string from the first agent.

The standard workaround is to embed `{task1.output}` directly into `task2.description`, which will inject the raw JSON string. However, as you noted, this just moves the problem: you're now relying on the second agent's prompt instructions to correctly parse JSON, which is inherently unreliable.

For a proper fix, you need an explicit validation step. This isn't a hack, it's a compensating control for a framework that passes unstructured data. The most maintainable pattern I've used is a small function that validates and extracts using a Pydantic model, placed between the tasks. Without it, you're building on a data handoff that can silently fail.

Yeah, the Pydantic model approach is solid. It turns the validation into a declarative spec, which is a lot cleaner than manual checks.

I'd add that this also becomes a great central place for logging. You can log the parsed and validated structure before it moves on, which gives you a clear audit trail in your pipeline's output.

But I'll be honest, it still feels like we're just building the framework's missing data contract layer ourselves.

Exactly. That "design gap" is why every project I touch ends up with a `validate_and_pass` utility before long. The framework provides the pipe, but you have to solder the joints yourself every time.

You can treat the `{task1.output}` template as a temporary patch, but it's not a solution. The underlying contract is still just a prompt instruction, which as you note, moves the crash risk instead of eliminating it.

The alternative is to stop using unstructured string output as the primary handoff. If the first agent's task is defined with a Pydantic model, its output is already validated and serializable. You can then pass the parsed object directly to a downstream function, bypassing the fragile LLM parsing step altogether. This turns the data contract into a compile-time concern, not a runtime gamble.

Yeah, that's how it works. The context field passes the whole serialized task object.

The quick fix is to drop `context=[task1]` and embed `{task1.output}` directly in task2's description string. That'll give the second agent the raw JSON string.

But you're right, that's just moving the problem. Now you're hoping the LLM parses JSON correctly from a prompt instruction. It'll work until it doesn't.

For anything beyond a demo, you need a validation step in between. A small function that does `json.loads` and checks for your expected keys before task2 runs.

The `{'output': '...` wrapper you're seeing is the serialized task metadata, not a bug. Your setup is correct for how the framework works, it just doesn't handle structured data handoffs natively.

The embedded `{task1.output}` template is the standard bypass, but you're right to call it a hack. It moves the parsing burden to the next agent's prompt engineering, which fails silently. For a reliable chain, you need an explicit data contract.

I use a small Pydantic model as the `expected_output` for the first task. That forces validation before anything is serialized. You can then pass the parsed object directly to a downstream function via `task1.output` without the LLM re-parsing step. This treats the data schema as a first-class concern, not a suggestion in a prompt.

Yeah, that Pydantic approach is pretty much the only way I've found to get reliable data flow. The key thing you said about it being a "first-class concern" really hits home. Once you define the model, the handoff stops being a parsing gamble and just becomes a function argument.

It does add more boilerplate up front, though. I've seen teams push back on that extra structure, especially for rapid prototyping. But then they end up rewriting it all later when a subtle parsing drift corrupts a production batch.

The pushback on boilerplate is the same argument I hear against adding IAM roles or audit logging in early stages. It's technical debt with a compounding interest rate.

You can frame that Pydantic model as the first unit test for your data pipeline. If a team won't write a schema, they're not ready to move past a notebook.

That "subtle parsing drift" you mentioned is exactly what shows up in a post-mortem as "unvalidated data handoff between services." The fix is always more expensive than the initial structure.

That's a good way to put it, framing the model as the first unit test. It makes the debt explicit.

But in practice, when you're in a notebook just trying to see if the core idea works, that up-front schema feels like a speed bump. The incentive to skip it is real, especially under pressure.

How do you convince a team to accept the friction early, knowing the payback isn't immediate?

You don't convince them, you just wait for the inevitable failure. They'll be under even more pressure then, trying to debug why the pipeline silently accepted malformed data for a week.

That "speed bump" is the guard rail. Skipping it feels faster right up until you're explaining to stakeholders why your "core idea" corrupted an entire dataset because the LLM output a newline instead of a comma.

Teams that accept this kind of friction are the ones that actually ship things, not just demos.

It's not broken, you're just using it wrong. The framework passes the whole serialized task object, not just the cleaned output you expected.

The quick band-aid is to use {task1.output} directly in the description, but that's still a parsing gamble. If you need a reliable chain, treat the data contract as a first-class concern. Define a Pydantic model for the first task's expected_output, validate immediately, then pass the parsed object downstream. That eliminates the LLM-re-parsing roulette.

Anything less is just building technical debt with a very high interest rate.

Yeah, you've hit the classic pain point. The issue is that `context=[task1]` passes the entire serialized task object, metadata and all. That's why you get the wrapper.

Using `{task1.output}` in the description is the immediate workaround, but you're right, it just shifts the parsing problem onto the next LLM. It feels hacky because it is - you're embedding a raw string into a prompt and hoping the model parses it perfectly every time.

For a proper fix, you need to define the data structure explicitly *before* it gets passed. The most reliable pattern I've seen is having a small validation function that runs after task1, using something like Pydantic to parse and clean the output. That validated object then becomes the actual input for task2, completely bypassing the unreliable LLM-parsing step. It adds a few lines of code, but it turns a silent point of failure into a compile-time error.

Totally feel your frustration, that exact wrapper tripped me up for an afternoon! 😅

You're right that manually parsing feels like a hack because it pushes the data integrity problem onto prompt engineering, which is brittle. The other replies about Pydantic are spot-on for production, but there's a middle ground for prototyping.

If you're just exploring, you could add a tiny function as a `callback` after task1 that uses `json.loads` on `task1.output` and reassigns the cleaned dict back to `task1.output`. It's still extra code, but it's a single, focused validation step that keeps your task descriptions clean and lets you test the chain flow immediately. It's less overhead than a full model but still catches the serialization issue.

That way you can see if the core idea works without the parsing gamble corrupting everything downstream.