Checking agent output before it reaches your next workflow step

Tips & Tricks
1

Disclosure: I’m building Penny Engine.

An agent can return valid JSON while still missing required fields or producing values outside your expected range. Penny Engine checks supplied assertions—required fields, expected values, and numeric ranges. It does not verify factual accuracy.

The intended workflow is:

Agent output → QA report → your workflow decides whether to continue or flag the result.

You can start with a free input-compatibility check using the sample and downloadable Python client:
https://penny-agent-api-production.up.railway.app/integrations/start.md

For n8n, the HTTP Request integration instructions are here:

The free check validates input compatibility; completed QA is a separate paid operation. The guide explains the Apify purchase route and spending cap. The full customer n8n-to-paid-execution flow hasn’t yet been independently verified.

Which output failure causes the most trouble in your automations: missing fields, unexpected values, or inconsistent results across a batch?

2

Answering the question at the end: inconsistent results across a batch cause the most trouble. A missing field is loud, because the next node throws; a batch where 3 of 400 items carries an out-of-range value fails quietly and shows up weeks later as a wrong number in a report.

n8n can also do the assertion step in-workflow, which keeps the check inside the same execution:

  • Pin the shape at the source with a Structured Output Parser on the agent node and an explicit schema. It makes the model retry when the JSON does not match, so most missing-field cases never reach the next node.
  • Then a Code node that asserts only what you care about: required fields present and non-null, numeric ranges, allowed values. Throwing on failure marks the item failed and routes it to the error workflow instead of letting a bad value through.
  • Guard the loop: on a failed assertion, call the agent once more with the validation message appended (2 attempts max), then quarantine the item for review rather than continuing.

Two caveats for any checker, external or not: the assertions are only as good as the ones you wrote, and none of them can tell you whether a value is true. An external hop also sits inside the execution, so a slow check becomes your workflow latency. Log the raw model output with each item so a failed assertion can be replayed without paying for the model call again.