Software project estimation usually asks a practical question: how much work remains before a defined completion state is reached? Agentic workflows can improve the answer by making estimation assumptions explicit, attaching size estimates to trackable work units, projecting those estimates into calendar dates, and feeding delivery outcomes back into future estimation guidance. The central opportunity is not that agents can guess better than people. It is that agents can help make estimation more repeatable, inspectable, reviewable, and correctable in large organizations with complex requirements, legacy systems, and cross-team dependencies.

Conflict detection for requirements needs a formal substrate that can update after small repository changes without rechecking the whole repository. This post proposes a restricted Datalog model, uses OPAM package metadata as a concrete benchmark, and reports a FlowLog run where incremental commits took 0.89 ms at p50 while batch recomputation took 783.6 ms at p50 over the same 30-commit window.

An agent loop is usually described as a practical control pattern: execute, observe, validate, revise, repeat. That framing is useful for building systems, but it hides a more basic question. If one agent loop can inspect and steer another agent loop, and another loop can inspect and steer that steering loop, do we get a genuine hierarchy of problem-solving power?

Large repositories need continuous semantic maintenance. A practical inconsistency resolver would treat a Git monorepo as a versioned knowledge base, use deterministic checks where possible, spend bounded agentic and formal-reasoning budget on high-value candidate artifact groups, and open reviewable pull requests that repair drift across code, tests, documentation, schemas, configuration, and mirrored external systems.

This is a work-in-progress side-project setup for me, at most 4 worker hosts, 1 public box, and 1 monorepo. The aim is to maximize AI subscription usage and hardware usage while minimizing my oversight.