Skip to content
Agent Model Fit

FieldworkImplementation retrospective

Building Agent Model Fit: Right Agent, Right Model, Right Problem

By Agent Model Fit

Published
On this page

Building Agent Model Fit has produced a practical lesson: an agent assignment needs a human-owned objective, a reviewable result, and a clear boundary between preparing work and authorizing its use. Model choice sits inside that contract. The available record supports an account of decisions and corrections; it does not establish which model performs best or how much time the process saves.

For digital and IT leaders, the useful question is whether another person—or another agent—can inspect a piece of work and determine what was requested, what changed, what was checked, and what still needs a decision.

A publication with a defined job

The owner’s recorded objective was to build an independent publication about matching agents and models to problems, serving digital and IT leaders first. The publication would use agents in its own operation and explain the resulting decisions and limitations. The existing AstroPaper foundation supplied a static site; the project did not need an agent platform, database, or autonomous publishing service to begin that work.

This account draws on internal editorial-direction and decision records dated September 5, 2026. They describe early Copilot implementation and stronger-agent strategic work. That is recorded project history, not an independently measured comparison of the systems. Those records do not establish exact model versions, complete prompts, or the number of attempts for the early work.

The distinction matters. A commit identifies a change. Its author field does not, by itself, identify the model that generated a suggestion or show how much human intervention the change required.

What the record lets us inspect

The following episodes are selected from one publication build. The underlying repository and project records are private; the editor has an exact file and commit inventory. These summaries are offered as first-party evidence, not as publicly reproducible test results.

DateInspected record and what it establishes
September 5, 2026Editorial direction and decision record. What it establishes: The recorded audience, human-control principles, and choice to document the build itself. It does not verify every earlier conversation.
September 7, 2026Execution-policy and agent-entry-point change. What it establishes: The repository added a Codex entry point and explicit execution metadata, and removed the active Copilot instruction file. Earlier Copilot work remains part of the history.
September 7, 2026Publishing workflow. What it establishes: A written procedure separates draft preparation, technical validation, review, and publication authority. A written procedure is not proof of enforcement in every run.
September 7, 2026Documentation correction and its closeout. What it establishes: Review corrected a malformed Node.js prerequisite and stale analytics follow-up wording. This was a documentation correction, not a demonstrated runtime defect.
September 9–10, 2026Calendar review and revision. What it establishes: Review identified overlapping topics and unclear evidence/public-link boundaries; the revision changed planning documents. Editorial acceptance remained a separate decision.

The September 7 instruction change marks the documented move to the later Codex/CXS workflow. CXS, the Context eXchange System used here, stores project intent, work orders, decisions, and handoffs in versioned files. Git establishes the actual branch, revisions, and file changes. Neither can substitute for the other: a state report can become stale, while a diff alone does not explain why the owner wanted the change.

A work order makes the boundary inspectable

AMF’s later workflow puts a bounded assignment into a work-order registry. The assignment identifies outputs, required checks, approval boundaries, and a stop point. An agent checks the branch and working files, reads the current context, performs the authorized work, and returns a validation record with logical commits for review.

The model-routing policy assigns different kinds of work to different roles: mechanical changes, ordinary implementation, and consequential judgment or review. Those are operating defaults. The policy explicitly separates requested routing from observed execution and leaves unavailable usage, cost, and speed data unknown. A role label is not evidence that a model ran or met a quality threshold.

The important artifact for a reviewer is therefore more than an output file. It is the output plus its intended use, supporting evidence, actual checks, known gaps, and the decision the reviewer is being asked to make. This is AMF’s interpretation of what the operating records make possible, not a measured claim that reviewers finish faster.

One small correction exposes a larger review problem

The publishing-workflow review found a malformed prerequisite: a minimum Node.js version had been split into Markdown that obscured the comparison operator. The correction restored >=22.12.0, matching the project’s existing engine requirement. The same correction commit updated an analytics follow-up that still described an installation as pending after it had already been recorded as implemented and promoted.

Both errors concerned the relationship between instructions and actual state. A build could succeed while a future operator still received confusing setup guidance. A handoff could preserve an obsolete next step even though the code had moved on. The closeout identifies the changes as documentation-only and distinguishes review of existing evidence from rerunning local checks.

Our takeaway is specific: review should examine whether instructions still match the repository and whether the next action remains authorized. This episode does not demonstrate that the process catches all errors. The record does not supply a denominator of inspected defects, undetected defects, or review attempts, so there is no defensible error-prevention rate to report.

Technical readiness and editorial judgment answer different questions

The later calendar review provides a second boundary. Structural checks could verify a 26-slot plan and four briefs. They could not decide whether two topics offered sufficiently different reader value or whether an internal source was appropriate for public disclosure. The revision addressed planning details; it did not automatically confer editorial acceptance.

The distinction is also present in article handling. At the inspected baseline, the site’s source filter excludes drafts, while the humanReviewed metadata field is not a rendering gate. The publishing procedure requires a separate approval record. Treating a field name as an enforced control would misdescribe the implementation.

Small commits help us locate these decisions: a reviewer can inspect the workflow correction separately from the policy introduction or calendar revision. They provide traceability, not immunity from mistakes. Human review still needs to assess the substance and the accumulated change before release.

What this build has not established

This is a retrospective of a single static publication, with selected records from September 5–10 inspected on September 11. It is not a production study of enterprise workflows. No controlled task set, complete run count, verified per-run model inventory, intervention log, or comparable cost and elapsed-time measurements supports this account. Historical validation reports are reports of earlier work, not newly repeated experiments.

The record therefore cannot support productivity, savings, traffic, reliability, or model-superiority claims. It also cannot establish that every handoff was complete or every approval boundary was technically enforced. Those are questions for separately designed evaluations.

A useful first experiment in your own process

Choose one reversible task and write down the intended result, the evidence a reviewer will need, the actions the agent may take, and the decisions it must return to a person. Ask the next reviewer to reconstruct the assignment from the output and handoff without relying on chat history. Record what the reviewer cannot determine. That is a proposed exercise, not a procedure tested by this article; the gaps are its most useful output.

Provenance

Prepared for Agent Model Fit with material Codex assistance in evidence inspection, organization, and drafting on September 11, 2026. Earlier Copilot implementation is reported from project records and is not relabeled as Codex work. Exact source locations and diffs are retained in the private editorial review packet; no private logs or repository access links are reproduced here. Human editorial review, including approval of the selected disclosures, was completed by Cresencio on September 11, 2026.