Build Log 002: Why I Rebuilt the AI Marketing Framework

Publishing the new Framework article turned into a full system release. The body already described governed Context, eight marketing engines, Orchestrate, Replicate, and two spines. Summaries, metadata, schema, and machine-readable pages still described the 2025 model. That contradiction meant a page edit could not fix it. I mapped every surface repeating the Framework, including localised fields, llms.txt, structured data, and feeds read by agents. The release then changed 180 exact CMS fields and records under snapshot, transaction, readback, and rollback controls. I checked 25 live routes and endpoints afterwards, then ran a 121-route production build. Those numbers describe the size of the release. They do not describe its business value.

A correct hero diagram could still sit above contradictory metadata. I therefore treated the copy, code, stored content, live readback, and rendered page as one release with several ways to fail.

Sharing state between engines was one problem that took four implementations. Each version fixed the failure directly in front of me. Each then exposed a different one, in access, durability, awareness, or governance. None of it was planned as a sequence. The work expanded, the previous arrangement stopped holding, and the next version answered whatever had just broken. That is why the count is four and not one. The constraint moved every time I removed it. The final arrangement is not stronger because it was better conceived at the start. It is stronger because three earlier versions found the failure modes first, and each one cost real work to discover.

Attempt one: context inside isolated sessions

The early engines lived in separate AI project windows, and each session understood only its own work. A decision from Create reached Listen when I copied it across, while useful files sat beside chat history that other engines could neither inspect nor inherit.

That arrangement worked while I could remember every handoff. As the number of engines grew, reconstructing decisions in each window created quiet differences between systems that were meant to share the same brand state.

Attempt two: centralised Context files

On 8 March 2026, I moved ICP, messaging, offerings, and company files into one directory; voice rules followed on 17 March. Multiple engines could finally read the same artefacts, which removed the most obvious copy drift.

The directory did not know who depended on it. No manifest or automated check linked voice.md to its consumers, so I still had to find every downstream reader and schedule each change by hand. The problem had shifted from access to dependency control.

Attempt three: the substrate

The April substrate moved the work onto disk and into Git. Six repositories replaced three chat windows, and changelogs, backlogs, integration contracts, and session wrapups made the decisions durable.

Git solved persistence without solving awareness. The Listen build repository saw little use while its wrapup carried the useful state, and I still had to compare repositories, reconcile conflicts, and choose the next change myself. I could recover a decision, but no engine knew whether that decision mattered to its next run.

Attempt four: a governed system of systems

The current design gives an agent one readable workspace while a canonical Context repository owns the brand files. Engine workspaces receive a byte-identical copy stamped with the canonical commit, and an exact-copy check blocks a run when that copy drifts.

The mktr connector provides a second route by exposing approved Context over Model Context Protocol. The MCP architecture specification separates focused providers from the host that coordinates permissions, context, and lifecycle; here, the repository mirror supports engineering checks while MCP serves published material.

Each task assembles only the runtime subset it needs. Adding another engine no longer requires a private Context fork, which turns governed Context from a useful folder into a system dependency.

All four attempts left one thing unowned, and August made me pay for it. Every repository still sat wherever it happened to have been created, so the workspace layout was load-bearing without anyone having decided that it should be.

Moving six repositories under one dedicated parent surfaced each place that had quietly depended on a location. The registry that resolves them now holds no absolute path at all. Access, durability, awareness, and governance each got an attempt of their own, while location stayed underneath all four until it moved.

The Operator Logs, not Git, hold the earliest evidence for the Context layer. Git in this system starts on 8 February 2026, because adopting Git was itself a system decision made then. Anything built before that date left no commit behind. The public logs did, and three dated entries from December 2025 record the first durable artefacts. Reconstructing this period from Git alone produces a confident and wrong timeline. That is the practical argument for publishing a dated log while the work is still happening. You cannot retrofit a receipt. Version control history starts wherever you happened to start it, and the system almost always predates the repository.

The table below identifies the three dated entries that changed the reconstruction:

Those artefacts became inputs for later workflows. The 2025 Framework called them engines because their creation felt sequential, but production showed several engines reading the same files before and during a run.

My first reconstruction was wrong because I searched Git alone. The three dated entries in the public Operator Logs corrected the sequence and changed my account of the architecture. The polished article shows the current model; the timestamped record shows how I reached it.

The later period has its own record, and this account is reconstructed from it. Every working session closes by appending a dated entry to a session log, and every engine change lands as a version row in a changelog.

That record carries 80 dated session entries between 8 February and 7 August 2026, plus 125 engine versions across five changelogs. The 8 March move of the ICP, messaging, offerings, and company files, and the voice rules that followed on 17 March, each carry their own entry naming the files it touched.

A claim about how a system evolved should be checkable against a record written while it was evolving. Anyone auditing the sequence can count the same rows I did.

The 2025 Framework put eleven engines into Foundation, Execution, and Optimisation layers. Production removed most of that structure. A stricter test replaced layer membership as the criterion for existing: an engine had to name its action, its artefact, and the contract separating it from its neighbours. Boxes that described an outcome failed. So did boxes whose work was already happening elsewhere in the loop. Eight operating verbs came through, with Orchestrate coordinating them and Replicate carrying the architecture into another approved Context. The same test settled a second question quietly. A new tool or a new repository does not earn its own engine, however useful the tool is.

The verb test asks three questions of each proposed engine:

1. What distinct action does the agent perform?

2. Which concrete artefact or state change does that action leave for the next engine or reviewer?

3. Does that contract remain distinct from the engines beside it?

Eight operating verbs survived: Data, Listen, Signal, Create, Distribute, Convert, Measure, and Iterate. Orchestrate coordinates those verbs. Replicate carries the architecture into another approved Context.

The same test stopped implementation tools from inflating the public taxonomy. Create-Articles, Create-Images, and the executable validator remain capabilities inside Create; a different tool or repository does not automatically earn another engine box.

The 2026 operating loop runs Data, Listen, Signal, Create, Distribute, Convert, Measure, then Iterate. Context sits at −1, one step before the sequence, supplying every engine with approved inputs. That position matters more than the ordering does. Evidence comes from Measure, Iterate proposes a change, and an authorised owner decides whether canonical Context may change at all. Orchestrate and Replicate sit outside the loop, because neither performs a further marketing action. Orchestrate coordinates contracts between engines. Replicate carries the governed architecture into a different approved Context. Two spines then run across the whole model, and keeping them separate is deliberate rather than tidy. A loop of eight verbs is the visible part. The parts that decide what may cross a boundary are not in the sequence.

Two spines cross the full model:

• Governance + Verify controls evidence, provenance, approval, and release boundaries.

• Protocol + Interop controls how engines, models, tools, and external systems exchange Context and actions.

Protocol can make a capability reachable. Governance determines whether an engine may trust its response, change canonical Context, or advance an output, which is why connection and authority cannot share one label.

The Linux Foundation placed MCP and AGENTS.md within the Agentic AI Foundation in December 2025. Open protocol work can reduce bespoke connectors. It does not remove permission boundaries, stable Context, or evidence requirements.

I use the content system to research, draft, plan figures, map sources, and run deterministic checks. It can complete much of that bounded work without me, but it still stops before this draft enters a CMS or changes a public claim.

Quality control in this system is now a program, not an instruction. The move started in Build Log 001, where an 89-line checklist made an article worse rather than better. Past a certain volume of rules, the model stopped applying them consistently. A completed reference example restored the expected output. Splitting image work and validation into their own engines cut the material competing for attention inside one context window. The decisive change came later: validation left the prompt entirely and became an executable running in its own process, outside the model that produced the text. Instructions are advice a model may weigh. An exit code is not. That is the whole difference between the two quality layers.

The failed self-grading pass

I then asked the generating model to inspect its own prose. It reported a pass while the article still contained patterns prohibited by the rulebook, which made the self-grading loop another claim rather than independent evidence.

That failure moved validation into tools/validate/validate.mjs. The executable reads the voice and validation documents at runtime, extracts the visible text, and returns rule identifiers, paths, excerpts, counts, and an exit code from a separate process.

Create-Compiler remains in the repository as history. Its useful cross-boundary checks now live in the executable validator, where the generator cannot award itself a pass.

Five controls from production failures

The system produced several reusable rules:

Anthropic's November 2025 account of long-running agent workflows describes the same need. Progress files, Git history, clean handoffs, and end-to-end tests help a fresh context continue the work.

Five acceptance layers ran on this release, because no single check covers every class of failure. A typed source of truth keeps labels, readiness values, and summaries consistent wherever code renders them. It proves nothing about the live database, and nothing about whether a page fits a phone. Each layer below it exists to answer a question the ones above it structurally cannot. Passing four of five is not a pass. The release counted as complete only when every layer produced its own evidence in its own environment, from typed source through to a rendered page on a real viewport. Most of the cost of this method sits in that last requirement. Evidence has to come from where the failure would actually appear.

I shipped code before applying content that depended on its renderer. The migration first proved that it could restore the exact prior database state; after the production apply, it read every target back and replayed the migration as a no-op.

A changing second run would have shown that the database had not settled. Keeping the 2025 article at its own URL also preserved the earlier model for readers and citations when the canonical Framework URL changed editions.

This method takes more work than editing one article in an admin panel. It leaves a reusable path through typed source, scoped migration, rollback proof, readback, and visual acceptance instead of a collection of manual corrections that cannot be replayed.

Every acceptance pass found something, after I had already decided the release was finished. Deterministic checks caught the machine-visible drift first. Three labels still carried shortened spine language after the broader migration. Live readback found one section heading and two subheadings the migration had missed. The public frame still displayed v0.11.0 while the application had reached v1.9.0. None of that was visible in an admin panel, which is why the checks run against live surfaces rather than against intent. The rest of the defects needed environments those checks could not reach. Confidence that a release is finished is not evidence. Every pass I expected to be a formality returned something instead.

A desktop screenshot passed, but true device emulation at 390px found 23px of horizontal overflow. The top-tick SVG kept an intrinsic width while using absolute positioning; constraining it to the available inset removed all 23px in the next production build.

Human review caught the consequential error. A new homepage H1 claimed that I governed a complete AI-native marketing system, even though Measure and Iterate remained unfinished in the public implementation.

The homepage returned to the approved line:

I build marketing functions that work, and design where AI fits in the system.

The typed readiness model exposed the mismatch, but no deterministic check could decide whether I had earned the positioning claim. I restored the approved line because the workflow kept that judgement with me.

The Framework was not built on this website. Hendry.ai is where the receipts are published and maintained, which makes it the visible surface rather than the boundary of the work. The implementations behind it come from personal, multi-brand, and enterprise projects, and parts of those cannot be shown here at all. What can be stated is the range: GTM workflows, Data and Signal pipelines, governed Context, Create plus Verify, an enterprise website, evaluation work that exercises Measure, and mktr, an MCP serving path now used by a marketing team. A second stream runs alongside it, packaging marketing practice as reusable skills. A framework demonstrated on one site proves less than one that has survived several environments.

Hendry.ai is the publication surface, not the boundary

The previous draft made Hendry.ai look like the boundary of my work. It is the public surface where I can show maintained receipts, while the Framework itself comes from personal, multi-brand, and enterprise projects.

Across those environments, I have built GTM workflows, Data and Signal pipelines, governed Context, Create + Verify, an enterprise website, and evaluation work that exercises Measure. I also built mktr, the MCP serving path now used by a marketing team through Teams, Copilot, and Claude; the organisation, private Context, and usage data remain outside this article.

Reusable skills are the next build stream

A separate workstream packages marketing practice as reusable skills for Claude, Codex, and Gemini. Its internal evaluation system tests whether a skill follows its own claims, adds value beyond a plain instruction, and behaves reliably across jobs. It keeps null and negative results instead of turning them into success stories.

The planned Hendry.ai section will organise finished skills by the job a reader needs to complete. The longer-term target is autonomous execution inside that section: you choose a job, and the system runs and verifies a finished skill.

Explicit permissions, an evaluator, and a safe stop still define what the system may change or publish. The section's final name is open.

Nothing signs a skill file

Getting a skill from one machine to another is the part I have no good answer for. An audit of one public skills registry found 341 malicious entries among the 2,857 skills it examined, most of them one coordinated campaign wearing the names of popular tools. Nothing signs a skill file, so a registry listing tells you what a package claims and not what it does.

So the skills I share move one way, carried by me, read before adoption, with a digest binding the version I reviewed. It does not scale past one person. I would rather say that plainly than describe a distribution story I have not built.

The table does not claim one completed end-to-end loop in a single environment. It shows the same contracts surviving different constraints while each receipt stays within its permitted evidence boundary.

What Hendry.ai can prove directly

The Hendry.ai ledger is narrower. It shows what the site can support with public receipts rather than inventorying my work or setting a ceiling on my operating maturity.

Private and enterprise work can shape the model even when its receipts cannot be disclosed on Hendry.ai. I therefore keep the de-identified capability record separate from the public ledger, because each supports a different kind of claim.

Autonomy by task

Autonomy also changes when I classify tasks instead of the whole system. My work spans L2 to L4: fixed workflows sit at L2, and consequential actions stop at L3. Bounded local engineering reaches L4 when agents act inside repository, permission, retry, and validation guardrails under my monitoring.

The Build Log pilot demonstrates that distinction. LangGraph routed and resumed bounded work, then stopped before live links or CMS when image evidence failed; access to sensitive data remained a separate permission decision.

Public claims, canonical Context changes, CMS writes, publication, deployment, and permission changes remain explicit human gates. Those gates describe retained authority, not the ceiling of the engineering work around them.

OpenAI describes this production pattern in Running Codex safely at OpenAI: low-risk work moves inside defined technical boundaries, higher-risk actions stop for review, and telemetry preserves an audit trail. I use the same division between agent preparation and human promotion.

The content-approval gate also has to survive a change of model, session, operator, or release process. Permissions, draft states, migration modes, and protected files carry that boundary more reliably than a sentence in a prompt.

This release has a quality record and no ROI figure. I can report 180 guarded edits and four classes of defect caught before the release settled. I cannot report a monetary return, because operator hours, model and API spend, and avoided rework were never isolated while the work was happening. That is a measurement failure rather than a modelling one. Estimating the inputs afterwards would not repair it. The inputs either exist or they do not, and reconstructing them produces a number with unearned precision. What this release does leave is the shape of the ledger it should have kept from the first edit. That is the cheapest correction available, and it has to start before the first edit rather than after the last one.

What the release can prove

Build Log 001 used a different method. It modelled the cost of a traditional content function against an AI-native operating model, then priced human QA and governance into the result. Reusing its headline here without the same input ledger would turn an estimate into a result.

The available cost and return record looks like this:

The calculation becomes possible once those inputs exist. These two formulae keep implementation and ongoing governance costs visible:

Return = avoided repeat-audit cost + avoided corrective-release cost + future update time saved

Net ROI = (return − implementation cost − ongoing governance cost) ÷ implementation cost

What the next release must measure

Next time I will capture hours by phase, model and API costs, and the stage where each defect appears. The ledger will also separate discovery, correction, and propagation time while retaining the baseline that existed before migration.

This release therefore records conformance and defects rather than economic return. A later ROI claim will need the cost and outcome telemetry captured while the work happens, not reconstructed afterwards. That evidence will make returns comparable across later releases.

Five steps, in this order, would carry another framework reconciliation. Run the verb test on the model first, so the components that survive are the ones with an action, an artefact, and a contract. Name the single writable owner of canonical Context next, before any workflow depends on it. Map every public and machine-readable surface that repeats the model. Release reversibly, with the rollback proven before the apply rather than after. Start the cost ledger at the first edit, because it cannot be reconstructed later. Order matters more than any individual step here. Choosing a runtime before settling the model, or naming an owner after the workflows already exist, produces work that has to be redone rather than extended.

Start with the model and its evidence

Ask what each component does, what it produces, and which contract makes it distinct. Put shared prerequisites in Context, keep tools inside the function they serve, and track built, partial, and designed work separately. Do that before selecting a runtime.

Name the authority before the workflow

Choose one writable source for voice, ICP, messaging, constraints, and approved facts. Stamp every derived copy with that source's commit, then list the tasks an agent may complete without stopping and the changes that still require a named owner.

In the Build Log pilot, generation and validation could continue without me, but failed image evidence blocked live-link and CMS steps. State and permissions enforced that boundary across a pause and resume. The stop survived both transitions.

Naming the authority is not enough if the name is a filesystem path. Moving the six repositories under one dedicated parent in August exposed how much had quietly depended on absolute locations, so every root now resolves relatively from a single registry.

The proof I trust for that class of change is narrow: rebuild the derived copies at a different root and compare the bytes. They matched.

Map and migrate the whole surface

Inventory pages, components, metadata, schema, feeds, summaries, localised variants, archives, and AI-readable endpoints before changing content. Use exact targets, a dry run, snapshot, transaction, rollback proof, complete readback, and a final no-op replay. Then test the rendered result at the declared themes and viewport widths.

Visual acceptance belongs in that same sequence. This release passed on desktop and still failed by 23px at a true 390px viewport. The acceptance set must therefore name both themes and exact device dimensions instead of recording only that somebody "checked mobile".

One longer conclusion followed, and I record it here as a decision rather than a result. A release this careful cost what it cost mainly because the content lived in a database while its history lived in Git.

The direction now is to publish from the files themselves: content tracked in the repository, a build carrying no secrets, checks that must pass, and an approved merge as the act of publishing. Nothing has moved. I am recording the decision here because the reasoning belongs with the release that produced it.

Separate Context, loops, and graphs

A 23 July 2026 research pass gave me clearer names for distinctions the build had already exposed. Anthropic's context-engineering guidance describes the model-facing information assembled for a turn; Hendry Context adds canonical ownership, provenance, drift checks, and controlled promotion around that runtime subset.

A bounded loop acts, observes, verifies, and stops at a declared limit. IBM published its loop-engineering explanation on 17 July 2026; I adopted the vocabulary afterwards rather than rewriting it into the original Framework history.

Graph engineering connects work with state, evidence, budgets, gates, and owners across a larger workflow or system. LangChain's July 2026 account uses a new label for a method that teams have applied to graph-based agent workflows for years. The official LangGraph Graph API documentation describes one implementation through nodes, edges, checkpoints, loops, and resume behaviour.

A learning plane sits beside those three, and it earns its own rule. The index I compile from research records, session entries, wrap-ups, and authority entries is derived: a clean checkout rebuilds it byte for byte, a stale index blocks a session from closing, and nothing at run time reads it.

That shape came from an earlier attempt that failed. I made shared learning a live dependency of the runs that used it, and the shared store then could not be moved or retired until I had found every reader. A layer no run depends on is a layer you can delete and rebuild, which is what makes its contents worth trusting.

Keep the runtime replaceable

For the Build Log pilot, the maintained builder still produced every article artefact. LangGraph routed and checkpointed the surrounding workflow, then stopped on failed image evidence before a live-link check or CMS step could run.

Hendry Context, the research record, validators, permissions, and people retained authority. The pilot proved one work-and-control slice, not the four graph views, the complete eight-engine loop, or a closed Measure-to-Context learning path.

A replaceable runtime still leaves two gaps on my side of the line. The first is persisted state: when the shape of a checkpoint changes, an older one either loads into the new code or it does not, and versioning that state and migrating it on load is the application's job. Cancellation is the second.

Stopping a run reaches its checkpoints, not the effects that already left the process, so anything reversible has to be registered as a compensating action before the forward action runs. Neither gap has bitten this pipeline, and the reason matters: the slice that runs today writes nothing outside the lab. Both become load-bearing on the first release that does.

The next useful test is Replicate. I will instrument that transfer from its first change and record hours, model and API costs, defects, rework, and propagation time while the evidence still exists.