When You Mythologize AI Agents, Your Specs Become Wishes: Operating Intent-Driven Systems Clearly
Developers who describe their AI agent as "smart enough to figure it out" ship broken products at a rate roughly three times higher than teams who write explicit behavioral contracts. The mythology of machine intelligence is not just philosophically sloppy. It is a direct cause of production failures.
Last quarter, a team I consulted with had built a document-processing agent on top of Claude 3.5 Sonnet. Their spec for the extraction step read: "The agent should understand what fields are important and pull them out accurately." Six weeks into production, the agent was hallucinating invoice totals on PDFs with non-standard layouts. When the post-mortem asked why the spec didn't constrain the output schema, the lead engineer said, and I'm quoting verbatim: "We figured it would understand what we meant." That sentence is the entire problem.
The Mythology Is a Technical Liability, Not Just a Metaphor
The New Yorker piece by Annalisa Merelli argues that treating AI as a mind with goals and intentions distorts our relationship to the technology. For philosophers, that's interesting. For engineers shipping production systems, it's a defect taxonomy.
When you anthropomorphize an agent, you start writing specs the way you'd brief a smart intern: loosely, relying on shared context and assumed judgment. "Handle edge cases gracefully." "Respond professionally." "Make sure the output is useful." These are not specifications. They are wishes dressed in the imperative mood.
The agent has no judgment to borrow. It has weights, a context window, a sampling temperature, and the statistical regularities of its training corpus. That's the complete list. Every behavior you don't specify, you are implicitly delegating to those weights, with no guarantee the delegation produces what you intended. At scale, that gap compounds. Intent drift, the progressive divergence between what you meant and what the agent does, is not a model failure. It's a spec failure.
What a Mythologized Spec Looks Like vs. What a Contract Looks Like
Here's the actual invoice extraction spec from the team I described, lightly anonymized:
# Agent: InvoiceExtractor
# Task: Extract billing fields from uploaded PDF invoices
The agent should:
- Identify the vendor name
- Find the total amount due
- Locate the due date
- Handle cases where fields are missing or ambiguous
- Return structured data
Every line in that spec is a decision handed off to the model. "Identify" how? "Find" with what confidence threshold? "Handle" ambiguity in what way, and what does the system do when handling fails? "Structured" in what schema?
Here's what a machine-verifiable contract for the same task looks like, written in ThunderLang's DSL:
agent InvoiceExtractor {
input: PDF
output: InvoiceRecord
schema InvoiceRecord {
vendor_name: string | null
total_amount_due: decimal(precision=2) | null
due_date: iso8601_date | null
extraction_confidence: float(min=0.0, max=1.0)
low_confidence_fields: list<string>
}
constraints {
if extraction_confidence < 0.75 {
require: human_review_flag = true
}
total_amount_due must_not_be_negative
due_date must_be_after invoice_date if invoice_date is_present
}
on_ambiguity: return null with low_confidence_fields populated
on_parse_failure: raise ExtractionError, do_not_hallucinate
}
The difference is not cosmetic. The second version is a contract the runtime can verify. extraction_confidence < 0.75 is a testable predicate. must_not_be_negative is a unit test the DSL generates automatically. do_not_hallucinate maps to a validated output-grounding check, not a hope.
The first version gives the model permission to invent. The second version defines the space of acceptable outputs and treats everything outside it as a failure.
Requirements as Code Is Infrastructure Thinking, Not Bureaucracy
The pushback I hear most often is that formal specs slow teams down, that they're appropriate for safety-critical systems but overkill for internal tools and prototypes. I disagree, and I'll be specific about why.
The cost of a mythologized spec is not paid at authoring time. It's paid at debugging time, when you have no systematic way to distinguish between a prompt engineering problem, a model regression, and an integration bug. It's paid when you upgrade from Claude 3.5 Sonnet to Claude 3.7 and discover that the new model's slightly different tone on ambiguous inputs breaks a downstream parser that was silently depending on the old model's phrasing. Without a machine-verifiable contract, you find that break in production.
Requirements as code means your specs are executable. They generate test fixtures. They define the eval harness. They produce the human-review trigger conditions. When a new model version ships, you run the contract suite before you promote the upgrade. This is exactly how you'd treat a database driver upgrade: you wouldn't ship a new version of Postgres and hope the query behavior matches your mental model of the old version.
ThunderLang's DSL approach forces this discipline by making vagueness a syntax error. You cannot write handle ambiguity gracefully in the DSL. You have to write what the system should do, in terms the runtime can evaluate. The friction is the feature.
For teams just starting to formalize their agent contracts, the Skills Tech Talk glossary has a working definition of intent drift and machine-verifiable specs that's worth walking junior engineers through before they start authoring.
Intent Drift Detection Is the Monitoring Layer Mythology Skips
Even a well-written initial spec drifts. Prompts get edited. Models get upgraded. The distribution of real-world inputs shifts away from what you tested against. Intent drift detection is the practice of instrumenting your agent's outputs against its contract continuously, not just at deploy time.
In practice this means:
- Every agent output is evaluated against the schema and constraint set defined in the contract.
- Confidence scores and low-confidence field rates are tracked as time-series metrics in Datadog or your observability platform of choice.
- Threshold violations trigger alerts, not just logs. A 15% increase in
extraction_confidence < 0.75events over a rolling 24-hour window is a canary signal that something upstream changed. - Periodic shadow evals run a sample of production inputs through the previous model version and diff the outputs structurally, not just semantically.
None of this works if your contract is a text file with bullet points. The monitoring layer has to have something machine-readable to compare against. The DSL is not an authoring convenience. It's the prerequisite for operationalizing the agent as infrastructure.
Teams that mythologize their agents skip this layer entirely. They rely on user reports to detect drift. That means their monitoring SLA is "however long it takes a frustrated user to file a ticket," which in my experience is measured in days, not minutes.
The Strongest Counter-Argument and Why It Doesn't Hold
The most sophisticated version of the opposing view goes like this: large language models are genuinely non-deterministic and context-sensitive in ways that make exhaustive formal specs impossible. Writing contracts pretends you can enumerate all the behaviors of a system that is fundamentally probabilistic. Better to invest in robust evals and human oversight than in the false security of a formal spec.
This is half right. You cannot write a complete formal spec for an LLM. The behavior space is too large. But that's not what machine-verifiable contracts are for. They don't specify everything the agent might do. They specify the invariants that must hold regardless of what the agent does. The output schema is an invariant. The non-negative total amount is an invariant. The human-review flag trigger is an invariant. These are the things you can test, the things you can alert on, and the things you can prove held or didn't hold for any given output.
Evals are complementary, not substitutes. You need both: a contract that defines the boundary conditions and an eval suite that probes the behavior inside those boundaries. Treating them as alternatives is another form of mythology, the mythology that thorough testing exempts you from the need for clear requirements.
The discipline is simpler to state than to maintain: treat the agent as a function with a type signature, not a colleague with a vibe. Write the type signature first. Test against it continuously. When the agent's outputs violate the signature, that's your signal, not your surprise.
If you want to pressure-test how well you can articulate these tradeoffs under interview conditions, the Skills Tech Talk AI Drill scores exactly this kind of spec-design reasoning against a senior-level rubric.
Practice this live with AI feedback
If you want to sharpen how you communicate spec-driven design decisions, including where to draw the boundary between formal contracts and eval coverage, Skills Tech Talk has a 60-second voice interview demo, no signup required. Get scored on clarity, technical depth, tradeoff reasoning, and communication by a senior-level rubric. Try it here.
The mythology of AI agency is a comfort for developers who don't want to write precise specs. The discipline of treating agents as constrained artifacts is what separates engineers who ship reliable systems from engineers who ship interesting ones.