Skill Issue or System Design? How LLMs Actually Follow Instructions

The checklist problem that exposes the model

Checklist tasks look boring. That is exactly why they are useful.

Ask an LLM to write a formal email under 50 words, include one required term, avoid another term, and return the result as JSON. None of this sounds intellectually difficult. No theorem proving. No multimodal reasoning. No dramatic benchmark leaderboard screenshot. Just instructions.

Then the model gives you 62 words, uses the forbidden term, and wraps the JSON in a friendly preface because apparently your schema was more of a lifestyle suggestion.

This is the production version of a research question: when LLMs follow instructions, are they using one general-purpose internal ability to obey constraints, or are they patching together many smaller skills—formatting, counting, filtering, topic control, sentiment control, style control—while generating text?

A recent paper by Elisabetta Rocchetti and Alfio Ferrara, How LLMs Follow Instructions: Skillful Coordination, Not a Universal Mechanism, argues for the second answer.¹ The paper is not saying models cannot follow instructions. It is saying the phrase “instruction-following ability” hides too much. The internal evidence looks less like one compliance engine and more like a coordination problem among partially shared, task-specific skills.

That distinction is not academic decoration. It changes how AI teams should test models, design guardrails, and allocate engineering effort. If instruction-following is one mechanism, then the obvious strategy is to find it, strengthen it, and steer it. If instruction-following is skill coordination, then the obvious strategy is less glamorous: decompose tasks, test constraint families separately, validate outputs at runtime, and stop pretending that one aggregate compliance score tells you much.

The second strategy is less elegant. It is also closer to how production systems fail.

Two stories: the compliance switch versus skill coordination

The paper is best read as a comparison between two competing stories.

The first story is the attractive one: instruction tuning teaches the model a reusable concept of “follow the rule.” Under this story, the model has something like a general instruction-following representation. It should appear across different tasks. It should transfer from one task to another. Removing it should damage many kinds of instruction-following. It should be detectable before generation begins, because the model has already understood the user’s constraint.

The second story is more mechanical: the model follows instructions by coordinating narrower skills. Counting words is not the same internal operation as staying on topic. Avoiding a word is not the same as producing non-toxic language. JSON formatting is not sentiment control wearing a different hat. Some skills overlap; others do not. The model may not “plan” compliance in advance so much as monitor whether the emerging output is still on track.

The authors test these stories using diagnostic probes on three instruction-tuned open models: Llama 3.1 8B Instruct, Gemma 2 2B IT, and Qwen2.5-0.5B-Instruct. They study nine tasks: character count, word count, JSON formatting, word inclusion, word exclusion, topic, sentiment, toxicity, and register. These tasks are deliberately ordinary. That is the point. They isolate the kinds of constraints that real products quietly depend on every day.

The datasets are also designed to avoid a cheap shortcut. Incorrect responses are not random nonsense. They are fluent but violate the requested constraint. A classifier therefore cannot win merely by detecting broken language. It has to separate successful compliance from plausible failure.

Here is the operational translation of the paper’s setup:

That table matters because the paper is not one result. It is a stack of tests, each aimed at a different failure mode of the universal-mechanism story.

The first crack: general probes are useful, but specialists win

The most direct test is simple. Train a specialist probe for each task and a general probe across all tasks. If there is a universal instruction-following representation, the general probe should be competitive across the board.

It is not.

The general probe performs below task-specific probes across the tested models. In the paper’s aggregate table, the general probe reaches mean accuracy of 0.68 for Gemma, 0.72 for Llama, and 0.63 for Qwen, while many individual tasks sit higher. Structural tasks are especially easy to detect: character count, term exclusion, and JSON format are around the low-to-mid 0.8 range across models. Topic, sentiment, and toxicity are weaker and more model-dependent.

This does not mean the general probe is useless. That would be too convenient. It captures something. But it does not capture enough to replace specialists. The business analogy is a dashboard metric that is directionally helpful and operationally insufficient. Fine for a board slide; risky as a deployment gate.

The layer-wise results sharpen the interpretation. Structural tasks such as character count, term exclusion, JSON format, and word count become detectable early, often reaching high accuracy within early layers. Later-emerging tasks—word inclusion, register, sentiment, topic, and toxicity—peak deeper in the network. The authors interpret this as a hierarchy of abstraction: structural and lexical controls appear earlier, while semantic and stylistic controls require later representations.

This is main evidence, not a decorative robustness check. It directly weakens the idea that one common compliance mechanism is doing the work everywhere. If different constraint types become visible at different depths, then “following instructions” is not one uniform internal event. It is a collection of task-relevant processes that mature at different points in the computation.

For product teams, this is the first useful correction: do not ask whether a model follows instructions. Ask which kind of instruction. Format compliance, lexical exclusion, topical control, tone control, and safety-style filtering are not interchangeable. A model that is excellent at JSON may still be mediocre at register. A model that can avoid a forbidden word may still drift off topic. Very annoying. Also very measurable.

Transfer patterns look like skill reuse, not universal compliance

The second test asks whether a probe trained on one task works on other tasks. Under the universal story, transfer should be broad. Under the coordination story, transfer should be selective: some related skills should share information, while unrelated ones should not.

The paper finds selective transfer.

One example is Llama’s topic probe, which transfers with relatively high accuracy to sentiment and term exclusion. That is not random. Topic and sentiment both require content-level judgment, and term exclusion can overlap with filtering behavior. But other probes remain highly specialized. The general probe also fails to consistently outperform specialists on held-out task data.

This is where the paper becomes more useful than a yes/no answer. It does not say every instruction skill is isolated. It says the sharing is clustered. That is exactly what one would expect from a system that reuses intermediate capabilities where useful but does not route everything through a single compliance module.

A simpler way to say it:

The key word is “asymmetric.” Cross-task relationships are not evenly mutual. A task can depend on information from another task without the reverse being equally true. The paper’s INLP ablation results show sparse, asymmetric dependencies rather than a dense common backbone. For Gemma, topic and word count depend on information from multiple other tasks. For Llama, topic depends on sentiment and term exclusion. For Qwen, register draws from diverse sources. The general probe’s information, when removed, has minimal impact on most specialist probes.

That last point is important. A universal feature that looks good in isolation but is not necessary for specialist performance is not a control handle. It is closer to an observational summary. Useful for interpretation, perhaps. Dangerous if mistaken for a master switch.

The ablation is the paper’s anti-magic trick

Probing papers often face a fair criticism: a probe can find information that exists somewhere in the model without proving the model uses that information. This paper tries to move beyond that by using Iterative Null-space Projection, or INLP. The idea is to identify the rowspace used by a probe for a source task, remove that information from activations, and observe how much a target probe’s performance drops.

The paper defines the normalized accuracy drop as:

This test is best read as an ablation: it asks whether information associated with one task is functionally important for another task’s probe. It is not a perfect causal proof of model behavior in deployment, because it operates through diagnostic classifiers and projected activations. But it is stronger than merely saying, “A probe found something, please be impressed.”

The ablation result supports the coordination story. If there were one central compliance representation, removing information associated with the general probe should damage many specialist probes. Instead, dependencies are sparse. Some tasks share. Many do not. The dependency graph has edges, not a giant glowing compliance node in the middle. Pity the diagram, but the model remains unmystical.

For business use, this has a direct implication: reliability failures should be debugged by constraint family. If a customer-support bot violates tone but returns valid JSON, the fix is probably not “improve instruction-following” in the abstract. It is tone/register evaluation, tone-specific examples, style constraints, runtime checking, and possibly task decomposition. The JSON layer is not evidence that the tone layer is safe.

Specificity varies by model, so model choice changes the control problem

The paper then asks whether these task signals are specific to constrained instruction-following or entangled with ordinary language modeling. The authors compare activations from constrained tasks with a null baseline: open-ended generation without chat templates.

This is a specificity test. It is not mainly trying to prove whether models comply. It is trying to tell whether the detected rowspaces are really about constraint satisfaction or whether they also light up during unconstrained text continuation.

The answer depends heavily on the model.

Llama shows the cleanest pattern. For most tasks, the null task intensities remain low, while success and failure distributions separate more clearly. This suggests Llama encodes relatively constraint-specific information. Qwen often shows null task intensities exceeding constrained task intensities for tasks such as character count, term inclusion, and JSON format. That implies the probe rowspaces may be picking up more general language-modeling features rather than clean compliance information. Gemma sits in between.

This result is easy to underuse. Many model evaluations collapse capability into a single score. The paper suggests that even when two models appear to perform similar tasks, their internal organization can differ. One model may expose cleaner, more constraint-specific signals; another may solve the task through noisier, more entangled features.

Cognaptus inference: this affects how easy a model may be to monitor, steer, or diagnose. It does not prove that Llama is universally safer or better for all enterprise workflows. It does suggest that model selection should include the shape of compliance, not just the surface success rate. A model whose compliance signals are less entangled may be easier to debug. A model that relies on general language features may pass simple tests while leaving fewer clean control surfaces.

That distinction matters for regulated or high-friction workflows. In a casual writing assistant, rough instruction-following may be enough. In a compliance review pipeline, procurement summarizer, legal intake tool, or data-extraction agent, “it usually follows the instruction” is not an evaluation strategy. It is a confession typed in product-manager dialect.

The model appears to monitor while writing, not plan before writing

The temporal result is the paper’s most intuitive finding for builders.

The authors probe different positions in the generation sequence: connector positions after the user prompt but before the model response, body tokens during generation, and the EOS token at the end. If constraint satisfaction were planned in advance, the signal should appear strongly before generation starts. If compliance is monitored dynamically, the signal should emerge once generation begins and persist through the response.

The paper finds the monitoring pattern.

Probe accuracy stays near baseline around connector positions, then rises sharply once generation begins. During the body of the generated response, accuracy stabilizes at high levels, roughly 0.85 to 0.95. At the EOS token, the paper observes a peak that may indicate a final verification phase.

This is main evidence for the second ranked contribution: instruction-following looks dynamic. The model is not obviously computing a complete compliance plan before the first output token. It appears to track constraint satisfaction while the output unfolds.

For system design, the consequence is almost painfully practical. If the model itself is doing much of its compliance work during generation, then external systems should also treat compliance as a runtime property. Validators, constrained decoding, schema checks, post-generation repair, tool-based verification, and iterative refinement are not “extra bureaucracy.” They match the apparent computational profile of the model.

The wrong lesson would be: “LLMs cannot plan.” The paper does not establish that. It studies specific constraint-following tasks, with specific probes, in three open instruction-tuned models. The better lesson is narrower and more useful: for these tasks, detectable constraint satisfaction does not behave like a strong pre-generation planning signal. So systems that assume one-shot prompt compliance are leaning on a mechanism the paper does not find.

PWCCA clustering turns instruction-following into a map, not a score

The PWCCA analysis is an exploratory extension, but a useful one. After extracting task-specific rowspaces, the authors measure representational similarity between task pairs and cluster them.

The result is not one universal map. Each model organizes task relationships differently.

Gemma forms two broad groups: lexical control clusters with semantic tasks, while structural formatting tasks form another group alongside register and sentiment. Llama isolates character count, then divides the rest into groups involving register, JSON format, term inclusion, and topic on one side, and toxicity, term exclusion, sentiment, and word count on the other. Qwen pairs term exclusion with toxicity, register with topic, term inclusion with sentiment, while structural tasks again form their own group.

There are recurring motifs. Term exclusion and toxicity often look related, which makes sense: both involve avoiding or filtering unwanted content. Structural formatting tasks also tend to cluster. But the architecture-dependent variation is the point. The same external instruction category can be internally organized differently by different models.

This is why “best model for instruction-following” is an under-specified question. Best for which constraints? Under which output format? With what validation layer? Under how many simultaneous requirements? And with what tolerance for repair loops?

A more useful evaluation matrix would look like this:

The table is not in the paper; it is the operational translation. The paper gives the reason this separation is necessary: the model’s internal organization does not justify collapsing all these constraints into one neat compliance score.

What the paper directly shows, and what builders should infer

Let’s separate the evidence from the business interpretation, because otherwise every model paper turns into either a product sermon or a disclaimer festival.

What the paper directly shows:

1. Across three instruction-tuned models and nine tasks, general probes underperform task-specific probes.
2. Cross-task transfer is limited and clustered, not broadly universal.
3. INLP ablation shows sparse and asymmetric task dependencies.
4. Structural and lexical constraints tend to become detectable earlier than semantic and stylistic constraints.
5. Constraint-specificity varies by model: Llama appears cleaner, Qwen more entangled with general language modeling, Gemma intermediate.
6. Constraint-satisfaction signals emerge mainly during generation and persist through the body, with a possible EOS verification signal.
7. PWCCA clustering shows model-specific task organization, with some recurring task-family relationships.

What Cognaptus infers for business practice:

1. Evaluation should be constraint-category based, not just task-aggregate based.
2. Runtime monitoring is not optional for high-reliability workflows; it is structurally aligned with how compliance appears to emerge.
3. External validators are especially valuable for structural and lexical constraints because these can often be checked deterministically.
4. Semantic and stylistic constraints need separate evaluation because they emerge differently and are harder to verify with simple rules.
5. Model selection should consider diagnosability, not just benchmark accuracy.
6. Fine-tuning and prompting should be treated as parts of a control stack, not substitutes for one.

What remains uncertain:

1. The experiments cover three open models, from 0.5B to 8B parameters, not the full frontier-model landscape.
2. The tasks are mostly single-constraint tasks. Real enterprise prompts often combine constraints, and conflicts among constraints may create new bottlenecks.
3. Diagnostic probes reveal information in representations; they do not fully explain the model’s decision process in every deployment setting.
4. The authors’ own framework depends on cross-layer representational comparisons, and they note possible alignment noise from transformations across layers.
5. Rowspace-based steering is proposed as a future direction, not demonstrated as a production-ready control method in this paper.

Those boundaries do not weaken the article’s core lesson. They keep it from becoming a TED Talk with equations.

The practical lesson: build the control layer around constraint families

The business value of this paper is not that it gives executives a new phrase, “skillful coordination,” to put in a strategy deck. Please do not do that.

The value is cheaper diagnosis.

When an AI workflow fails, teams often respond with broad remedies: rewrite the prompt, switch the model, add examples, fine-tune, or install a generic guardrail. Sometimes that works. Often it merely moves the failure from one constraint to another. The paper suggests why: the constraints are not all governed by one internal mechanism.

A better workflow starts with constraint decomposition.

For example, suppose an AI analyst must generate a client-ready investment memo. The instruction contains at least five constraint families: structure, citation discipline, topic relevance, tone, and risk wording. If the memo fails, the team should not record one failure label called “bad instruction-following.” It should mark whether the failure was schema, factual scope, missing citation, sentiment exaggeration, register, or policy language.

That creates a more useful engineering loop:

1. Identify the constraint family.
2. Choose the cheapest reliable validator for that family.
3. Repair deterministically where possible.
4. Use model-based critique only where rules are insufficient.
5. Track failures by constraint family across models and prompt versions.
6. Decide whether the fix belongs in prompting, retrieval, fine-tuning, decoding, validation, or human review.

This is less romantic than “the model understands the task.” It is also how reliable systems get built.

The same logic applies to AI agents. Agent workflows often fail not because the model lacks intelligence, but because the system asks one generation step to satisfy too many heterogeneous constraints. Planning, tool selection, format compliance, safety policy, memory use, and final-answer style are different skills. A single prompt can request them all, but that does not mean the model internally executes them as one coordinated plan. The paper’s temporal evidence makes that assumption especially fragile.

The limitation that matters most: multi-constraint reality is still open

The biggest practical boundary is not that the paper uses probes. That matters, but it is expected for interpretability work.

The more important boundary is that real workflows are multi-constraint. The authors explicitly note that future work should test prompts such as “Write a formal email under 50 words without using the word meeting.” That example is not exotic. It is Tuesday.

Multi-constraint prompts can create conflicts. A short answer may make tone harder. JSON formatting may reduce natural style. Safety wording may conflict with user-requested brevity. Entity preservation may conflict with anonymization. Each additional constraint is not merely one more checkbox; it changes the coordination problem.

So the paper should not be read as proving how all enterprise agents handle complex workflows. It gives a diagnostic foundation for why those workflows are hard. The next step is to test how constraint families interact when they are combined, prioritized, and repaired across multiple generation steps.

That is where product design becomes more important than model worship. The system can decide which constraints are deterministic, which are model-judged, which are hard stops, and which can be repaired after generation. The model alone should not be asked to silently resolve that entire hierarchy in one pass.

Conclusion: instruction-following is not a switch, so stop looking for the switch

The clean story would be nice. Instruction tuning creates a universal compliance mechanism; we find it; we steer it; the model follows instructions. Product reliability improves. Everyone claps. The end.

The paper gives a less convenient story and a more useful one.

LLM instruction-following appears to depend on coordinated skills. Some are structural. Some are lexical. Some are semantic or stylistic. Some transfer. Many do not. Some are cleanly encoded in one model and entangled in another. The relevant signal seems to emerge during generation, not as a completed plan before the first token.

For AI builders, that means instruction-following should be managed as a system property. Measure constraint families separately. Add runtime validation. Use repair loops. Choose models not only for raw output quality but also for the kind of compliance they make easier to diagnose. Treat prompts as one control surface, not the whole control system.

The model may be skillful. The product still needs design.

Cognaptus: Automate the Present, Incubate the Future.