AgroUnu · Lucian Murgu

At a glance

Problem: Farm records, inputs and sales must stay traceable end to end — and code written with coding agents must be checked by more than the agent’s own report.
My contribution: I designed and build the platform, its data architecture and the agent-evaluation process that gates each change.
Technical scope: Python / FastAPI API, PostgreSQL 18 + PostGIS 3.6, S3-compatible object storage, Next.js web app with a generated OpenAPI client, OIDC sign-in, tenant isolation.
Evidence: Recorded quality runs (Oct–Nov 2026): 485 passing API tests; 267 frontend unit checks; 34 production-browser checks with zero skips. Independent evaluator reports, including rejections.
Result: Working end-to-end farmer workflow on synthetic data — purchase → physical receipt → field work → harvest → sale → dispatch — across ten fictional demo farms.
Status: Pre-pilot. Not in production; real-pilot and staging release gates are still open.
Limits: Figures come from the project’s own recorded runs, not an external audit. Synthetic farms only; no measured farm outcomes yet. Source is private.

The platform

AgroUnu is an evidence-to-decision platform for crop farmers. It keeps the records a farm actually runs on — farms, fields and their boundaries on a map, crop cycles, planned and completed operations — and links every physical event to its paperwork: a purchase to its goods receipt, field work to the inputs it used, a harvest to the sale and the dispatch that followed.

The point is not another dashboard. It is that a farmer, an adviser or an auditor can follow any number back to the event and document that produced it.

Architecture

API: Python and FastAPI, with versioned database migrations and a locked data architecture.
Data: PostgreSQL 18 with PostGIS 3.6 for field geometry; an S3-compatible object store for documents and evidence files.
Web: a Next.js farmer app using a client generated from the API’s OpenAPI contract, so front and back cannot silently drift apart.
Access: OIDC sign-in, signed access tokens and tenant isolation between farms.
Review data: ten explicitly fictional Romanian farm scenarios with a deterministic builder and balance and geometry validators.

How it is built

Much of the code is written by coding agents — which is exactly why the process around them matters. Work is cut into bounded missions with a written contract. A builder implements; a separate evaluator, working only from the contract and the evidence, decides whether the mission passes. The evaluation policy defines six layers of checks, evaluator independence, and critical vetoes that no amount of passing tests can override. Missions include seeded contradictions — deliberate traps the checks must catch — plus adversarial cases, trajectory inspection and recovery records.

The evaluator is allowed to say no, and does. In one early system mission it rejected the builder’s work outright:

“SYS-01 is rejected. The decisive failures are: only five of six required seeded contradictions fail deterministically; …”

— independent evaluator report, AgroUnu programme

That rejection is the system working: a builder’s “done” was not accepted until the evidence said so.

Verification

Each consolidation run records its own quality gates. The most recent recorded runs (October–November 2026) report 485 passing API tests, 267 frontend unit checks, 34 production-browser checks with zero skips, type checking, linting, a production build and regenerated API contracts. Browser coverage includes the saved purchase-to-dispatch journey and tenant isolation between farms.

Status and limits

AgroUnu is pre-pilot. It has not served production traffic, and the real-pilot and staging release gates are open. Every result above uses synthetic farm data.

Test counts are what the project’s own runs recorded; a large test suite shows care, not production readiness. The source is private.

Related: the Consulting page describes how the same discipline is applied to client systems.