A developer project published on GitHub under the name Intent-Router is drawing attention from people who build with AI agents. The tool, described in its repository README as an intent compiler, takes a vague instruction such as 'add caching to the user API' and turns it into a typed contract called an IntentSpec before any code is written. Where the request leaves gaps, the tool first searches the available material for answers, and it asks the human only about the questions that no file can settle.
What the project does
According to the README, Intent-Router works in three passes. The first pass, called parse, turns the raw request into a draft specification with a normalized action, its objects, its explicit constraints and a list of unknown fields. Anything the model has to fill in on its own is tagged as inferred, so a reviewer can reject it at a glance.
The second pass, resolve, is where the project departs most clearly from common practice. Every unknown is classified before the user sees it. If an objective answer exists and the tool can reach it, the rule is to probe rather than ask. Questions are reserved for matters that live in a person's head or for decisions that cannot be reversed. The README gives examples such as package manifests, routing files, architecture decision records, ticket histories and account entitlements as places where answers may already be recorded.
The third pass checks the spec against a stopping condition. If the specification is sufficient and the question budget is spent, the tool emits it. If not, it halts and names the field that remains open. The README says the tool distinguishes two kinds of halt. An underspecified halt means the request is not yet decidable, and the next step belongs to the user. A degraded halt means a probe failed, a model timed out or a parse broke, and the README treats that as an operations signal rather than a question for the user.
The guessing problem it targets
The project's README frames the issue with an analogy to compilers: a compiler does not guess the address of an undefined symbol, and an agent should not guess what the user intends. The authors describe two common failures. In the first, an agent produces a large volume of confident work built on an assumption nobody made, and the user discards it after finding the premise wrong. In the second, the agent conducts a long interview, which the README says can run to dozens of questions, and the answers then disappear when the session ends.
The README argues that both failures share one root cause: nobody decided whether missing information was worth asking a person for. Intent-Router's answer is to make that decision explicit and recorded. Its design also tries to avoid a practical trap that the author says is common in similar routing libraries, where distinct failures collapse into one generic fallback. In that situation, a backend outage can quietly send all traffic to a default handler while logs show nothing unusual.
Why the saved file matters
Every run that produces a spec, according to the README, writes a machine-readable file to a folder called .intent before the reply reaches the user. The file records whether the intent is still waiting on a question, has been settled, or has already been carried out. Probed fields carry pointers to their evidence. A later session reads the file before probing anything, so a question already answered is not asked again, and a settled contract is implemented as written. When the delivered work is checked against the spec, the result is written back into the same file.
The README presents this as a way to keep a record of what a team actually decided. Instead of reconstructing the purpose of a pull request after the fact, a reviewer can open the file that sat beside the change. The authors say the file is the only thing written, that nothing is committed automatically, and that whether the folder belongs in version control is left to each project.
What the published results show
The README reports a comparison in which the same weak request was run against a fixture with the same permissions, once without the skill and once with it. The author reports five runs without the skill and three with it. In the bare runs, the README says, the code shipped with no failure path for the cache, so a downed Redis instance would take the request down with it. In all three skill runs, the tool asked one question that no file could answer, whether the cache should fail open or serve stale data, and then wrote the answer into the code. The README reports that all three delivered caches stated their failure policy, while none of the five bare deliveries did.
The README also reports a measured run from 23 September 2026, in which eight of ten cases in the project's suite passed and no evidence was hallucinated. These figures come from the project's own evaluation, and the README notes that the full suite results apply to coding tasks. Support-style tasks have a smaller measured footprint, so readers should treat claims about non-coding domains as more tentative.
How it compares with existing tools
The README positions Intent-Router against several neighbors. It acknowledges that many agent harnesses already prefer looking things up over asking, and that a good harness will often offer a sensible default. It also describes grill-me, a questioning skill, as effective at converging ideas but stateless, leaving no file behind. The README says spec-kit preserves more structure but requires adoption of a full workflow, and that Kiro's specification approach comes closer in spirit but depends on a full three-file workflow inside an IDE.
The project also cites two decision models, Jev and Laya. According to the README, both turn an already clear input into a typed decision in a single pass, and neither converges a vague request into clear input first. The README describes Jev as a closed API and Laya as an open-weights alternative compatible with Jev's wire format that can be run locally. The author lists both as possible future optional backends.
The README lists four differences it considers central. First, the contract outlives the session, because conversational answers are lost when a context is compressed or a model is switched. Second, probe failures and underspecified requests are kept distinct. Third, the tool halts rather than routing when an inferred value touches an irreversible boundary. Fourth, it challenges a premise only when evidence in the repository contradicts what was requested, and not because a different approach seems preferable.
Getting started and what to watch
The README says installation requires no API key and no dependencies, because the tool is distributed as a skill. Manual installation instructions are provided for agents that the installer does not recognize. The project's evaluation tables and schema documentation are included in the repository, along with worked examples of each decision state.
For teams considering adoption, the central question is whether the evidence probes reach the sources their organizations actually trust. The README makes clear that the approach depends on machine-readable records, such as decision files, tickets and documented policies. Teams with thin documentation will see fewer probes resolve and more questions reach users. Outside software development, the authors say the required evidence pointers change in form, for example to record identifiers or document sections, but the requirement that every probed field carry one remains in place. Whether that discipline holds up in practice across different domains is the question the next wave of published runs will need to answer.
Related: LFM2.5-24B-A2B: Liquid AI's Open Reasoning Model for On-Device Agents · Free n8n Workflow Builds Local Business Leads from Google Places
Comments (0)