Family Ledger moved from a shared Rust and SQLite gateway on a Hetzner VM into its own repository and Google Cloud project. Firebase Hosting serves the static Next.js application, Cloud Run scales the TypeScript API to zero, Firestore stores the ledger, and Cloud Scheduler posts weekly allowances. Terraform runs from GitHub Actions through workload identity federation. This post covers the architecture, free-tier cost model, bootstrap sequence, authentication, data migration, deployment pipeline, and provider details found during the cutover.

Agent-authored pull requests already contain much of the signal needed to improve agentic coding workflows: the prompt, opened diff, quality gates, review comments, revisions, merged state, model configuration, and token spend. The useful loop is to mine that lifecycle after merge, propose minimal guidance-surface or quality-gate improvements, retry the clarified task, and measure whether the extra token spend improves post-convergence one-shot success and value-per-token.

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?