Naming who you're not for is category clarity (Dunford) and strategic discipline (Rumelt: strategy is choosing what NOT to do). These are the specific conditions under which Intent cannot be safely adopted, regardless of how interesting the hypothesis sounds. If any of these apply to your team, we would rather lose you here than fail you in month three.
Signal: your team cannot safely revert a deploy within minutes.
Intent's trust formula weights reversibility at 20%. L3 and L4 autonomy brackets assume the infrastructure supports rollback. Without that capability, trust scores are calibrated against a property the environment cannot honor. A reversible decision that cannot actually be reversed is a fiction, and fiction-based autonomy is unsafe.
Signal: shipped code is immediately live for all users.
Intent's autonomy levels assume the ability to ship code that is still "off" until a human turns it on. Feature flags are how humans retain approval authority on impactful changes without bottlenecking the code advance. Without them, every L3/L4 action is irreversibly live, which collapses the trust framework.
Signal: tests are aspirational, manually run, or absent.
Intent's contracts are executable assertions — contract.assertion.passed means a verification command returned 0. If your team doesn't have real automated tests, contract verification becomes manual authorship (slow, biased) or absent (silent failure). Either path destroys the signal quality Intent's feedback loops depend on.
Signal: you have observability tools but nobody looks at them.
Forsgren's DORA research is unambiguous: measurement without visibility is cargo-cult measurement. Intent cannot generate valid signals from invisible measures. The load-bearing principle: if your development and your product isn't measurable and the measures aren't visible, it shouldn't be using our approach. It lacks the ability to generate and rely on valid signals.
Signal: your org assumes people will slack off unless watched.
McGregor's Theory X cultures use any new metric as a performance-evaluation input. Intent's trust scores will become surveillance in these environments. Signals with attribution will become dossiers. Spec clarity scoring will become individual critique. Intent's mechanisms do not have built-in protection against misuse by managers who read every score as a performance indicator. In Theory X cultures, adopting Intent will damage humans.
Signal: promotion and bonuses are tied to dashboards people don't control.
If your org tends to turn any visible metric into a performance-review lever, Intent's autonomy levels, trust scores, signal rates, and spec clarity measurements will become performance theater. The Safety Contract's Promise 1 (trust scores are about artifacts, not people) cannot be honored by a culture that does not already value that distinction. We do not have a policy override for this. Don't adopt.
Signal: low-safety teams where disagreement is interpersonally costly.
Intent depends on Edmondson's four dimensions of psychological safety. Specifically, it depends on people capturing signals about friction they notice, disagreeing with specs that seem wrong, and asking for help when stuck. In environments where any of these are socially punished, Intent's mechanisms fall silent and the system degrades to a fancy ticket tracker. The disambiguation signal pattern — "when stuck, generate a new signal asking a better question" — requires baseline safety to function. The Safety Contract is still a work in progress — the gap was flagged in the panel review.
Signal: SOX, HIPAA, FedRAMP, ITIL-heavy compliance frameworks.
Intent's file-native, git-tracked approach is designed to be auditable by engineers. It is not designed for audit teams trained on Jira, ServiceNow, or enterprise GRC tooling. In heavily regulated contexts, the audit function will reject git-based evidence for the same reasons it rejects Slack messages. This is not a technical gap — it's a vocabulary mismatch with compliance culture. Translating between the two is ongoing expensive work.
Signal: 8+ engineers in one team structure.
Intent is for teams of 2–7. Sweet spot 2–5. Over 7 is out of scope. This is not a claim that large teams can't use methodology — it's a claim that Intent specifically is not designed for large-team coordination. If you're managing 20 engineers, Intent is not your tool. Try Team Topologies, Flight Levels, or EBAT. We are not pretending to serve your use case.
Signal: AI tooling is occasional, aspirational, or absent.
Intent's hypothesis is specifically about what happens when implementation cost collapses via AI agents. If your team doesn't have daily AI tool use, the hypothesis doesn't apply yet — the bottleneck hasn't shifted for you. Come back when AI is part of the daily rhythm, not before.
Thanks for reading this far. If Intent isn't right for your context, here are methodologies that might be better aligned:
Large teams: Team Topologies (Skelton/Pais), Flight Levels, Disciplined Agile.
Regulated environments: SAFe (we don't love it but it fits audit cultures), ITIL-aligned delivery.
Low psych safety: Do the Edmondson work first. Read The Fearless Organization. Intent cannot be adopted before baseline safety exists.
No AI tooling yet: Continuous discovery (Torres), story mapping (Patton), outcomes-over-outputs (Seiden). Come back when AI is part of the daily rhythm.
No infrastructure: Do the continuous delivery work first (Humble/Farley). Intent's trust framework needs that substrate.