← Blog
#AI#LLM#Claude#Workflow#Developer Tools

Designing AI Assistants as a Workflow Runtime, Not a Chatbot

webhani·

From chat to runtime

How teams use AI assistants has shifted noticeably over the past year. A year ago, results came down to whether you could write a good prompt. In 2026, the deciding factor is whether you can build a system that reproduces the same quality of work every time.

Several write-ups on Anthropic usage patterns make the same point: people who treat Claude as a runtime for workflows — rather than a one-off chatbot — get far more value out of it (Let's Data Science). In our own consulting work with client engineering teams, the presence or absence of this mindset changes the outcome dramatically.

This post breaks down the building blocks for moving from ad hoc prompts to reproducible workflows, and how to assemble them in practice.

Five building blocks, split by role

In agentic tools like Claude Code, it helps to think in five layers. Each one applies at a different moment, so conflating them leads to surprising behavior.

  • CLAUDE.md (always-on context): project assumptions, conventions, and prohibitions the agent always reads
  • Skills (on-demand knowledge and procedures): playbooks invoked only for specific tasks
  • MCP (external connections): reach beyond the filesystem to issue trackers, databases, monitoring tools
  • Subagents (context isolation): run bounded work like review or tests in a separate context
  • Hooks (automation and guardrails): enforce rules on tool calls and session events

An easy way to remember it: CLAUDE.md is "always-on assumptions," Skills are "procedures on demand," MCP is "connections outward," subagents are "context isolation," and hooks are "automatic enforcement." Separating them by role keeps things clean when you add capabilities later.

CLAUDE.md: stop re-explaining the basics

CLAUDE.md has the best return on effort. Write your framework versions, naming conventions, how to run tests, and which files must not be touched once, and you no longer explain them in every prompt.

# Project conventions (excerpt)
 
## Tech stack
- Next.js 16 App Router / TypeScript strict
- Styling via Tailwind only. No CSS Modules.
 
## Do not
- Never hand-edit files under `src/generated/` (auto-generated)
- Never inline secrets in `.env.local`
 
## Testing
- Always run `npm test` before considering work done

The key is to spell out prohibitions, not just requirements. A short "do not" list prevents the model from breaking things while trying to be helpful.

Skills: make procedures reusable

If you keep asking for the same task, extract the procedure into a Skill. Routine work like "generate a blog post" or "draft release notes" can be saved as a trigger plus a set of steps, so it reproduces at the same quality each time.

Where CLAUDE.md is "always read," Skills are "read only when the conditions match." That lets you give the agent specialized knowledge without inflating the always-on context, which keeps behavior stable and avoids context pressure.

MCP: connect beyond files

MCP (Model Context Protocol) connects the assistant to systems outside the filesystem. It can read tickets from an issue tracker, query PostgreSQL, or check errors in a monitoring tool — turning the agent into something that operates real business workflows rather than editing files in isolation.

Permission design matters most here. Casually adding write-capable MCP connections raises the risk of unintended changes. When we roll this out for clients, we start with read-only connections, confirm the value, then open write access gradually.

Subagents and hooks: isolation and enforcement

Subagents are helper agents with their own context, prompt, and tool permissions. The main agent owns planning and integration, while bounded tasks — code review, running tests, security checks — go to subagents. This runs specialist work in parallel without polluting the main context.

Hooks attach to events like tool calls or session end and enforce rules mechanically. Common patterns include:

  • Run tests before allowing the session to stop
  • Block edits to generated files
  • Run the linter before a commit
  • Trigger a security scan after dependency changes

The value of hooks is that they do not rely on the model's good intentions. Like human review, it is safer to systematize rules on the assumption that they will otherwise be forgotten.

Our take: start small and measure

You do not need to adopt all of this at once. The sequence we recommend to client teams looks like this:

  1. Set up CLAUDE.md only. This alone changes perceived stability significantly.
  2. Turn one frequent task into a Skill. Pick something with visible payoff.
  3. Wire up one read-only MCP connection. Prove value with a safe connection first.
  4. Enforce test runs with a hook. Guarantee a quality floor mechanically.
  5. Isolate with subagents when needed. Start with review or tests.

The important part is measuring before and after — count rework cycles or review findings. Without numbers, adoption rarely sticks across a team.

Wrapping up

Results from AI assistants are no longer decided by the cleverness of a single prompt. Fix your assumptions with CLAUDE.md, reuse procedures with Skills, reach outward with MCP, isolate context with subagents, and enforce rules with hooks. Split those five by role, and your work becomes a reproducible workflow.

Start with CLAUDE.md. It is the easiest step and the one where you will feel the effect fastest.

webhani provides consulting on web development, cloud, and AI/LLM adoption. If you are integrating AI assistants into your workflows, we are happy to talk.

← Back to Blog