Zhiyuan Song
← Notes

Agent skills: constraints over scripted workflows

While wiring Claude Code Skills and watching multi-agent apps, one takeaway keeps getting sharper: putting agents inside clear, checkable constraints and boundaries is usually more stable—and easier to evolve—than freezing a “step A → B → C” workflow. The latter demos well; once real requests branch, it tends to rot or accrete patches.

When prescribed paths lose

Script-style flows assume enumerable world state and predictable intent. In engineering, tools return messy payloads, users change goals mid-flight, context gets truncated, and models occasionally drift. The more detailed the flow, the faster branch explosion arrives; every new corner case edits the spine of the workflow, and maintenance cost climbs.

Worse: workflows hard-code “how,” while leaving “what must never happen” and “what counts as done” underspecified. That invites tool calls when it shouldn’t, continuation when it should stop, and confident hallucinations when it should refuse—none of which is fixed by sprinkling extra ifs. You need boundary semantics up front.

Where I prefer to invest: constraints & boundaries

Axes that compound for me (stacked, not either/or):

  • Safety & permissions: which MCP endpoints / subprocesses are never reachable, which directories are read-only, which fields never touch logs—before “step 3 must call tool X.”
  • Output shape & contracts: granularity for users (one-line verdict vs executable checklist), when uncertainty must be stated, rules for citations and code fences—reducing damage from “sounds expert but isn’t.”
  • Stop / escalate / degrade: when the agent must hand off to a human, signals that trigger read-only retrieval without writes, when to discard a draft and retry—often higher ROI than polishing the happy path alone.
  • Observability & replay: minimal trails when boundaries fire, so you can diff prompt/tool versions later—fuel for iterating constraints themselves.

Intuitively, constraints are guardrails that still let the model reason inside them; workflows are rails that require a global re-lay whenever you derail. In frontier AI engineering, models and tools move fast—rails age faster than guardrails.

How this maps to an Agent Skill

In description, triggers, and rules files, I try to spell out first: when to activate, when to refuse, boundaries on tools and data, and the user-visible output policy. The exact “call sub-agent N at step k” wiring stays loose, stitched with checkpoints rather than micro-scripts—unless the domain is truly regulated (e.g., settlement, prescribing), where rails belong.

Versus “prescribed paths,” constraints-first feels like drafting a small constitution: few clauses, debatable, versionable. Workflows feel like ever-growing administrative code—more lines, more drift from the field.

Closing

This is not anti-workflow—it’s against using workflows as a substitute for boundary thinking. The hard part for agents/skills is reliable decisions in open environments; there, boundaries outlive paths. If practice changes, I’ll write another note to revise or narrow this claim.