One distinction I would add is between context and enforcement. AGENTS.md and SKILL.md can keep a correction close to the work, but they are still text the model can follow or ignore. In our system, when a failure repeats, we try to move the rule into the narrowest mechanical surface: schema, validator, gate, or workflow transition. The skill becomes a thin shim that invokes the process rather than the process itself. That also changes the compaction question. We can safely discard old tool output once the durable artifact, plan, or receipt holds the state that must survive. I would be interested in how Decode decides which corrections stay as memory and which should graduate into executable controls.
That's a great observation. I do something similar as well. I start with a pure skill that encodes the process, treating it as a PoC, then slowly move the code into a Python/TypeScript CLI that implements the process, while the skill only knows how to call the CLI.
But still, I don't do that all the time. For my coding factory, I personally don't think writing my own code will add a ton of value, but then I move logic into subagents where I keep the skill only as the main orchestrator.
Most of our core use cases are long-running software delivery workflows across many repositories: planning and decomposing a change, delegating bounded pieces, validating architecture and definitions of done, landing PRs, and closing out the work with durable evidence. The failure we kept hitting was that every agent could produce a convincing report, but the workflow state, permissions, and proof disappeared with the session or lived only in prose.
That is where we draw the line differently from using subagents alone. We still use agents for judgment, search, decomposition, and implementation. But repeatable steps such as contract validation, state transitions, CI and branch-protection readbacks, evidence collection, and acceptance gates move into typed handlers and command-line workflows. Skills, hooks, and MCP become thin ways to invoke those processes. A subagent can propose or execute work, but it cannot promote its own result into authoritative state.
The practical rule we use is: if the step benefits from judgment and exploration, keep it agentic. If it controls authority, mutation, durable state, or a repeatable test, make it mechanical. The part we're still working out is how quickly a successful subagent workflow should graduate into that form. Have you found a good signal for when the PoC has stabilized enough to compile into code?
I would add four signals: the step owns durable state, crosses an authorization or side-effect boundary, needs deterministic retry or idempotency, or must produce evidence another process can verify. Those are the places where harness logic becomes too weak even when the skill is clear.
Cost can favor keeping work inside a subscription-bound harness, but portability and enforcement pull the other way. We leave search, decomposition, and judgment agentic. State transitions, protocol adapters, validators, and acceptance gates move behind a CLI or service. The skill stays a thin interface, so the same process can be called from Claude Code, another harness, MCP, hooks, or directly. Your if-else point is often the earliest sign that the skill has become an accidental program.
I mostly just keep going until it degrades, which reading this now is clearly the worst option on your list. The microcompaction idea of swapping old tool outputs for a placeholder while keeping the tool input intact is the piece I hadn't considered, the agent can just rerun it if it actually needs the result again. Have you noticed /compact losing something important often enough that you've learned to manually intervene before it fires automatically?
Honestly I just keep going until it degrades, which is a bad habit I picked up because /compact has burned me before with a summary that dropped the one constraint that actually mattered. The microcompaction placeholder trick is the part I hadn't thought about, since it keeps the tool inputs rerunnable instead of just deleting context and hoping for the best. Might actually switch to compacting proactively at 60% instead of waiting for the wall.
The pattern I see with clients is the same with AI subscriptions: recurring costs get underestimated until they max out.
Budgeting for these tools as professional development—like a monthly SIP—is something most tech workers overlook.
It's the same discipline as retirement planning: plan for the recurring burn, not just the upfront gain.
100%, but using these techniques can help you trim down your token usage -> costs
One distinction I would add is between context and enforcement. AGENTS.md and SKILL.md can keep a correction close to the work, but they are still text the model can follow or ignore. In our system, when a failure repeats, we try to move the rule into the narrowest mechanical surface: schema, validator, gate, or workflow transition. The skill becomes a thin shim that invokes the process rather than the process itself. That also changes the compaction question. We can safely discard old tool output once the durable artifact, plan, or receipt holds the state that must survive. I would be interested in how Decode decides which corrections stay as memory and which should graduate into executable controls.
That's a great observation. I do something similar as well. I start with a pure skill that encodes the process, treating it as a PoC, then slowly move the code into a Python/TypeScript CLI that implements the process, while the skill only knows how to call the CLI.
But still, I don't do that all the time. For my coding factory, I personally don't think writing my own code will add a ton of value, but then I move logic into subagents where I keep the skill only as the main orchestrator.
What are your core use cases in your work?
Most of our core use cases are long-running software delivery workflows across many repositories: planning and decomposing a change, delegating bounded pieces, validating architecture and definitions of done, landing PRs, and closing out the work with durable evidence. The failure we kept hitting was that every agent could produce a convincing report, but the workflow state, permissions, and proof disappeared with the session or lived only in prose.
That is where we draw the line differently from using subagents alone. We still use agents for judgment, search, decomposition, and implementation. But repeatable steps such as contract validation, state transitions, CI and branch-protection readbacks, evidence collection, and acceptance gates move into typed handlers and command-line workflows. Skills, hooks, and MCP become thin ways to invoke those processes. A subagent can propose or execute work, but it cannot promote its own result into authoritative state.
The practical rule we use is: if the step benefits from judgment and exploration, keep it agentic. If it controls authority, mutation, durable state, or a repeatable test, make it mechanical. The part we're still working out is how quickly a successful subagent workflow should graduate into that form. Have you found a good signal for when the PoC has stabilized enough to compile into code?
That's quite similar to what I have.
Usually I consider:
- costs (running as skills within the harness runs under the subscription -> cheaper)
- I need to combine multiple models from multiple providers (tough to do within a single harness)
- I start to get locked into a harness (Claude Code) if I want to achieve what I want
- There are too many if-else scenarios within a skill where the agent starts to get confused
What would you add to this list?
I would add four signals: the step owns durable state, crosses an authorization or side-effect boundary, needs deterministic retry or idempotency, or must produce evidence another process can verify. Those are the places where harness logic becomes too weak even when the skill is clear.
Cost can favor keeping work inside a subscription-bound harness, but portability and enforcement pull the other way. We leave search, decomposition, and judgment agentic. State transitions, protocol adapters, validators, and acceptance gates move behind a CLI or service. The skill stays a thin interface, so the same process can be called from Claude Code, another harness, MCP, hooks, or directly. Your if-else point is often the earliest sign that the skill has become an accidental program.
All solid points! 🫶
Wow
Hehe 😜
I mostly just keep going until it degrades, which reading this now is clearly the worst option on your list. The microcompaction idea of swapping old tool outputs for a placeholder while keeping the tool input intact is the piece I hadn't considered, the agent can just rerun it if it actually needs the result again. Have you noticed /compact losing something important often enough that you've learned to manually intervene before it fires automatically?
Honestly I just keep going until it degrades, which is a bad habit I picked up because /compact has burned me before with a summary that dropped the one constraint that actually mattered. The microcompaction placeholder trick is the part I hadn't thought about, since it keeps the tool inputs rerunnable instead of just deleting context and hoping for the best. Might actually switch to compacting proactively at 60% instead of waiting for the wall.