Data-dependency thinking

How we actually build Agenoia — and the discipline most agent projects skip.

The consultant's version of this problem

Before Agenoia was an agent, this was a consulting problem. When a client asks for a report — say, unpaid invoices by client — answering it correctly means mentally tracing every source that number actually depends on: the invoice table, but also payment status, currency and exchange-rate handling, project state, credit terms, maybe a client-specific exception that's been in place for years. Miss one dependency and the number is wrong, confidently and silently.

An agent answering the same question has exactly the same problem — it just has no consultant's instinct to fall back on. Left to itself, it will call whichever tools are nearby and produce a confident-sounding answer regardless of whether it actually found every source the correct answer depends on.

Why this gets underestimated

A recent CIO.com analysis of enterprise agent failures made a version of this same point at the organizational level: agents don't fail because models are weak, they fail because businesses deploy them into processes nobody has actually mapped — and a model can't infer approval chains, exception paths or policy precedence from transactional data alone. That's the same failure one level up: an ungrounded agent, in an ungrounded process.

At the level of a single query, the equivalent mistake is treating "find the right data" as something the agent will figure out through general reasoning. It won't, reliably — not because it lacks intelligence, but because knowing which sources a question depends on is domain knowledge, not language ability. A word-count estimate for a translation job and an unpaid-invoice report don't share a data-dependency shape, and no amount of general-purpose reasoning substitutes for having actually mapped that shape out.

Making it explicit, per prompt

So we don't leave it implicit. For each class of query Agenoia needs to answer, we map its data dependencies before we implement it — not as documentation on the side, but as the actual thing that gets built: a named query, scoped to the sources that question genuinely requires, checked against ]po['s already-modeled business process rather than reverse-engineered from scratch.

This has a real cost, worth being honest about: it means the query catalog has to be actively maintained, and it doesn't automatically generalize to a genuinely novel question the way a fully open-ended agent would claim to. We think that trade is the right one for enterprise use — a smaller set of things Agenoia can answer *correctly and audibly*, over a larger set it can answer *plausibly*.

Where it breaks first: entity recognition

Before dependency-mapping even applies, the agent has to correctly identify what the question is about — which client, which project, which invoice. This is where a large share of everyday agent failures actually start, and it's rarely dramatic: an ambiguous name that matches two clients, a project referred to by a nickname instead of its coded reference, a relative date ("last month," "the Paris job") that resolves differently depending on when and who's asking.

Generic language models are not naturally good at this in a business-specific namespace — they weren't trained on your client list. Named entity recognition against your own data has to be treated as its own step, not folded silently into "the agent will understand what I mean." And critically: a low-confidence entity match should never be silently resolved to a best guess. It should trigger a clarifying question instead — the same verification/escalation self-model described on the self-modeling page, applied one step earlier in the pipeline, before the query even runs.

Why this needs domain knowledge, not just engineering

Mapping data dependencies accurately requires knowing the business, not just the schema — knowing that a "credit terms" exception exists at all, or that a translation project's true cost depends on a language-pair rate table most engineers would never think to check. That's the part that doesn't come free with a capable model, and it's the part twenty years of ]project-open[ consulting work already provides: the process knowledge most organizations are still trying to build from scratch before their agents can be trusted.

See how this plays out end to end in the before you deploy questions, or how it connects to the wider pattern of enterprise agent failure on the why agents fail page.