FIELD NOTES / 002 / OUR PHILOSOPHY

Good agents show their work.

A convincing explanation is a beginning. A result you can check is much more useful.

Imagine a retailer merging two billing accounts into one parent organization. Before the change, two order lines contain three and two units of the same product. Five units in total. A careless join after the migration matches each line twice. Suddenly, the pipeline sees ten.

A forecasting model might treat that as a surge in demand. A plausible explanation could follow. The first problem, though, is the join.

Make the checks part of the task.

In this illustrative example, two simple checks help: does each order-line ID still appear once, and does the total quantity reconcile? If either fails, publishing the forecast should wait. The pipeline should return the offending keys and transformation so the failure can be investigated.

This is the kind of behavior GraphForge is designed to explore. Successful execution is one signal. Passing the task’s domain-specific checks is another, and it matters just as much.

Evidence should travel with the result.

The proposed architecture keeps versioned code, identified inputs, and validation results together. Agents use a compact package of computed findings and artifact references. If they need more detail, they request another computation against the data.

That separation lets a person inspect how a number was produced. It also makes rerunning a known procedure possible without asking an agent to reinvent it.

Save progress. Don’t just repeat the level.

A repaired pipeline becomes a candidate for reuse. If definitions or data change later, its saved assumptions and checks provide a starting point for diagnosis. Comparing whole pipelines also means accounting for preparation, retries, latency, and operator effort alongside predictive quality.

Our working principle is simple: useful autonomy comes with something you can inspect.