16 posts tagged with "Workflow"

Andrej Karpathy's LLM Wiki is a small idea with an annoying amount of truth in it. Plain RAG is good at finding passages. It is much worse at keeping the synthesis alive after the answer is done.

That hurts in software work. A coding agent can read the release docs, scan the task history, find a half-forgotten migration note, and still leave the next agent to repeat the same archaeology next week. The useful part of the work was the cleaned-up map of what the project knows. The final answer was just one expression of that map.

That is what the LLM Wiki pattern is really about: raw sources stay raw, and the model maintains a wiki that gets better over time. Agentplane 0.6 takes that idea and makes it fit a Git repository.

Every team that works with coding agents eventually invents a small library of "the way we do things here." A release has a shape. A code-map task has a shape. A review response has a shape. Someone writes a prompt, someone else copies it, and a month later nobody knows which version is the real one.

Recipes are Agentplane's answer to that drift.

They are not meant to replace the project policy. They are not a second agent framework hiding next to the repo. A useful recipe is narrower than that: a reusable behavior package that can be installed, inspected, checked, and kept inside the same task lifecycle as normal work.

The hardest part of agent work is rarely the first draft. The hard part is knowing whether the agent is on the right route.

That sounds mundane until a task gets large. A release includes commits, but it also includes publication evidence. A migration includes file edits, but it also includes compatibility and rollback. A branch-pr close includes a merge, but the handoff matters just as much. Each of those jobs has a shape: the sources to inspect, the evidence to record, the checks that matter, and the point where the agent should stop instead of guessing.

Blueprints are Agentplane's way of making that shape explicit.

Coding agents can now produce large, plausible diffs faster than reviewers can reconstruct the work behind them. The missing object is not another dashboard. It is a durable artifact that travels with the repository.

Agent Change Record v0.1 is that artifact.

Coding agents are already good enough to change real repositories.

The weak part is not always the code they write. The weak part is the trail around the code: why the task existed, which plan constrained it, who owned the execution, which checks ran, and what made the work safe to close.

Agentplane 0.3 ended up being less of a feature line and more of a discipline line.

It started with a policy gateway and stricter release records. It ended with branch PR closure evidence, publish hygiene, recipe groundwork, and the first real modular prompt assembly layer. That is a lot for a 0.3.x series, but the pattern is easier to see in hindsight: every patch made the system less dependent on implicit agent judgment.

The final published 0.3 release is v0.3.29. A maintenance branch now preserves that line as 0.3. The next release is being prepared as 0.4.0 because prompt modules are not just another patch. They introduce a new mental model for how Agentplane builds agent instructions.

Agentplane 0.4.0 is published.

The headline is modular prompt assembly: agent instructions, policy gateway material, generated agent profiles, and runner prompt inputs now move through a shared module graph instead of being treated as large prompt files copied from place to place.

That sounds internal, but it changes the shape of the product. It gives Agentplane a stable layer where future recipes can patch, bind, disable, or validate named behavior without rewriting an entire prompt surface.

Agentplane 0.3.8 and 0.3.9 make more sense as one release story than as two separate announcements.

0.3.8 was the preparation patch. It split oversized modules, collapsed duplicated execution paths, and pushed the CLI, task lifecycle, backends, and runner toward shared contracts that 0.4 and 0.5 will need anyway.

Then the release itself exposed a hole in the publish contract. The npm artifact for 0.3.8 shipped with a workspace: dependency on @agentplane/recipes, so plain npm install agentplane failed with EUNSUPPORTEDPROTOCOL before the CLI could even start.

0.3.9 is the corrective half of that same work. It removes the leaked workspace dependency, adds a release parity guard that fails publishable manifests containing workspace: references, and tightens the hook-runner fallback used by release and upgrade flows.

That is why this is one release story. 0.3.8 showed where the codebase was going. 0.3.9 fixed the part that proved the release process was not strict enough yet.

Agentplane 0.3.7 is a patch release about making the product behave more honestly when the repository is old, the backend is external, or the release path is under stress.

That sounds broad, but the theme is consistent. 0.3.7 removes a set of half-implicit transitions that were still too easy to treat as “probably fine”:

• legacy task docs that upgraded in two separate mental steps,
• Redmine state that still behaved too much like a projection-only shadow,
• release publication that needed stronger exact-SHA and artifact-backed recovery rules.

0.3.7 makes those boundaries much sharper.

Agentplane 0.3.4 is the version where the product finally stops assuming that users live inside the framework repository.

That sounds obvious, but it matters. The main distribution path is npm i -g agentplane, not “clone the framework repo and learn its internal file layout.” Once that becomes the real product lens, a few behaviors that looked acceptable from inside the framework stop being acceptable at all.

0.3.4 fixes that.

Agentplane 0.3.3 is the release where a lot of framework-internal friction finally turned into explicit product behavior.

Before this version, several important things still worked more by convention than by contract. Runtime selection inside the framework repo could be confusing. Task docs carried too much historical baggage. Local CI was correct but expensive. Release recovery was real, but not fully codified.

0.3.3 tightens all of that.

Agentplane 0.3.2 is a cleanup release, but in the good sense. A bunch of things that had been treated like “yeah, that’s annoying, we know” finally got fixed properly.

The biggest wins landed in upgrades, direct-mode task closure, and framework development inside the Agentplane repo itself.

Agentplane 0.3.0 is where the policy layer stopped feeling like scaffolding and started acting like product surface. Before that, the rules could work and still be hard to follow. This release cleaned that up.

Agentplane 0.3.1 is a recovery release in the most literal sense. It exists because the 0.3.0 npm path was already burned, and pretending otherwise would have made the release story worse, not better.

Agentplane 0.2.25 was the sort of release that looks small until you have to trust it. No shiny headline feature. Just a stricter workflow, fewer accidental commits, and a cleaner release path.

Agentplane started as a CLI that keeps repository work honest. The roadmap to 0.5 is not about turning it into a vague “AI platform.” It is about adding explicit execution-route contracts and a cloud backend option without losing the audit trail or the policy boundaries that make the tool usable in a real repo.