{
  "access": "public",
  "type": "reference",
  "format": "markdown",
  "title": "Guided Navigation: Tool Meshes as Dialog Trees",
  "url": "https://labs.datagrout.ai/papers/guided-navigation",
  "summary": "An agent facing an enterprise tool mesh faces a scale problem disguised as a reasoning problem. Hundreds of tools across dozens of integrations cannot be loaded into a context window, so the agent works from search results and partial schemas, and the mesh's most consequential structure, the typed paths *between* tools, never enters its view. Autonomous planners answer part of this: search the type graph, rank candidate plans, commit to one. But commitment is wrong for a class of workflows (the trap-prone, the ambiguous, the policy-sensitive) where the correct next step depends on judgment the planner does not have and the agent cannot exercise over options it never sees.\n\nGuided navigation turns workflow construction into a dialog. The platform derives a decision tree from the same symbolic planner that powers autonomous planning and walks the agent through it one step at a time: here are your options, each with a label, a cost, and a viability verdict; choose one; here is what that implies; choose again. The agent never sees tool schemas or the mesh itself; options are the compression channel, a few lines per turn against a mesh of arbitrary size. Because the guide *presents* rather than *ranks*, it can surface what an autonomous planner must bury: the expressive query passthrough that loses on type-fit but wins on capability arrives flagged and recommended, with live grounding (real field names, dialect constraints) attached at the moment the agent must write a query. A guided session is a plan under construction, not an execution transcript, so backtracking is exact and free, and a completed traversal is generalized into a parameterized, certified, reusable skill.",
  "topics": [
    "tool-discovery",
    "workflow-construction",
    "planning",
    "skills"
  ],
  "content_markdown": "## Abstract\n\nAn agent facing an enterprise tool mesh faces a scale problem disguised as a reasoning problem. Hundreds of tools across dozens of integrations cannot be loaded into a context window, so the agent works from search results and partial schemas, and the mesh's most consequential structure, the typed paths *between* tools, never enters its view. Autonomous planners answer part of this: search the type graph, rank candidate plans, commit to one. But commitment is wrong for a class of workflows (the trap-prone, the ambiguous, the policy-sensitive) where the correct next step depends on judgment the planner does not have and the agent cannot exercise over options it never sees.\n\nGuided navigation turns workflow construction into a dialog. The platform derives a decision tree from the same symbolic planner that powers autonomous planning and walks the agent through it one step at a time: here are your options, each with a label, a cost, and a viability verdict; choose one; here is what that implies; choose again. The agent never sees tool schemas or the mesh itself; options are the compression channel, a few lines per turn against a mesh of arbitrary size. Because the guide *presents* rather than *ranks*, it can surface what an autonomous planner must bury: the expressive query passthrough that loses on type-fit but wins on capability arrives flagged and recommended, with live grounding (real field names, dialect constraints) attached at the moment the agent must write a query. A guided session is a plan under construction, not an execution transcript, so backtracking is exact and free, and a completed traversal is generalized into a parameterized, certified, reusable skill.\n\n---\n\n## Problem Landscape\n\n### The Mesh Does Not Fit\n\nA connected enterprise exposes a tool surface far beyond context scale, and the surface is the *small* part: the consequential structure is which tool's output feeds which tool's input, through which type adapters, at what cost. Agents given search over this mesh see isolated tools; the paths stay invisible, and multi-step workflows get assembled by guesswork over fragments.\n\n### Ranking Buries Capability\n\nAn autonomous planner must order its candidates, and ordering follows type-fit. But some of the most capable tools in any mesh are the *expressive* ones: raw query interfaces that can answer almost anything and type-check as almost nothing. A ranker cannot responsibly put \"write a query\" above a clean typed path; a presenter can put both in front of the agent, labeled. The failure this prevents is concrete: a chain of fixed-shape tools that *almost* expresses the required filter, producing plausible and wrong results, where the passthrough would have expressed it exactly.\n\n### The Blank Query Box\n\nWhen an agent does choose an expressive tool, it faces the inverse failure: a query language, an unknown schema, and dialect restrictions it discovers by erroring. Observed failures cluster here: aggregates on fields that forbid them, date functions the dialect lacks, invented column aliases. The information that prevents every one of these, the org's actual field names and the dialect's actual limits, exists on the platform and is absent at the moment of writing.\n\n### Exploration Should Not Execute\n\nInteractive workflow construction over real enterprise systems has a safety precondition: trying a path must not perform it. If each step executes as it is chosen, backtracking means undoing side effects, and exploring a payments workflow is indistinguishable from operating one. *Choosing* has to be separated from *committing*.\n\n---\n\n## Design Principles\n\n### 1. Options Are the Interface\n\nThe agent's view of the mesh is the option list: identifier, human-readable label, estimated cost, viability, and the reason where blocked. Tool names, schemas, and argument shapes stay server-side. This is a compression claim and a governance claim at once: the context holds a handful of lines regardless of mesh size, and the platform controls what is presentable at all.\n\nThe design's model is the text adventure, the multi-user dungeon in particular. A player in a MUD never sees the map. They see a room description and a list of exits, they type one, and the world describes the next room. The map lives on the server, the world is explored on rails the server lays down, and the player's whole interface is the choice at hand. Guided navigation puts an agent in that position over a tool mesh: each node is a room, each option an exit, the recorded steps the path walked, and backtracking the way back. What the analogy buys is discipline about what crosses the wire. A room description is a few lines however large the dungeon; the exits are the only moves; and the world can put a signpost on the exit it recommends, or bar one with a reason, without ever showing the player the whole graph.\n\nOne turn, against a mesh of arbitrary size, is a few lines:\n\n```json\n{\n  \"position\": \"step_2\",\n  \"options\": [\n    { \"id\": \"1\", \"label\": \"Aggregate opportunities by owner (typed chain)\",\n      \"cost\": 3, \"viable\": true },\n    { \"id\": \"2\", \"label\": \"Query passthrough — write the filter directly\",\n      \"cost\": 2, \"viable\": true, \"recommended\": \"expresses 'exclude renewals' exactly\" },\n    { \"id\": \"3\", \"label\": \"Export to spreadsheet tool\",\n      \"cost\": 5, \"viable\": false, \"reason\": \"step budget exceeded\" }\n  ]\n}\n```\n\nThe recommended passthrough (option 2) is the one an autonomous ranker would have buried under the clean typed chain. Here it arrives flagged, with its rationale, and the choice stays with the navigator.\n\n### 2. Present, Don't Rank\n\nThe tree is *derived* from ranked plans but *presented* as alternatives. Presentation frees the system from the ranker's constraint: it can inject options the search buried (the query passthrough is surfaced whenever recall finds it and its integration is in play for the goal) and flag a recommendation with its reasoning, while leaving the commitment to the navigator. A recommendation the agent follows produces a different failure profile than a ranking the agent never saw.\n\n### 3. Plan, Don't Execute\n\nChoosing an option records a step; it does not run a tool. The session accumulates a plan: steps, arguments, dataflow, cost. The single exception is the grounded query, below. Because navigation only plans, going back is exact: pop the step, recompute the accumulated state, re-present the parent's options.\n\n### 4. Ask With the Answer Attached\n\nWhen a chosen option requires input the platform cannot infer, typically the text of a query, the session enters an input-requested state carrying not just the ask but the *grounding*: the org's real field names for the entities in play, the dialect's constraints, an example of the shape required. Today that grounding is assembled for one dialect, SOQL against Salesforce; other passthroughs receive the ask without it, and per-dialect grounding wherever a passthrough exists is the intended path.\n\n### 5. Never Dead-End\n\nA navigation step with no prepared continuations grows the tree at runtime: the platform joins the current tool's output types against the catalog for type-compatible successors, re-ranks them against the goal, and appends one synthetic terminal alongside them: *save what you have built so far as a skill*. Where the join finds no successors the node terminates and the session compiles from where it stands.\n\n---\n\n## Architecture\n\n### One Planner, Two Interfaces\n\nGuided navigation and autonomous planning share a substrate: the same goal decomposition, the same embedding-seeded candidate search over tools and semantic types, the same symbolic A* over the typed tool graph (see *Semio: A Semantic Interface Layer for Tool-Oriented AI Systems*), the same policy pre-filtering, the same compiled-plan validation. They diverge at the last step: the autonomous interface returns ranked, executable plans with typed input holes and one-call execution handles; the guided interface reshapes the same plans into a navigable tree of single-step choices.\n\n```mermaid\nflowchart TB\n    subgraph S[\"shared planning substrate\"]\n        direction TB\n        g[\"goal\"] --> d[\"goal decomposition\"]\n        d --> c[\"embedding-seeded candidate search\"]\n        c --> p[\"policy prefilter\"]\n        p --> a[\"symbolic A* over the typed tool graph\"]\n        a --> v[\"compiled-plan validation\"]\n    end\n    v -- \"autonomous\" --> r[\"ranked executable plans<br/>typed input holes, one-call handles\"]\n    v -- \"guided\" --> t[\"navigable tree of single-step choices\"]\n    t --> i[\"inject the passthrough<br/>flag a recommendation<br/>collapse duplicate routes\"]\n```\n\n*Both interfaces run the same pipeline up to validation; only the last step differs, and the guided branch then reshapes the plans it was handed.*\n\nAutonomous planning suits a well-shaped goal the caller wants answered in one round-trip, and carries its own refinements for that regime: post-execution verification with bounded, escalating correction, and a lean mode returning exactly one plan, because agents handed many interchangeable alternatives thrash between them. A plan is also certified at plan time: the recommended plan's certificate is persisted with its evidence at stage `planned` and remembered by the execution handle, and when the handle is performed the run's certificate lists the planned one as a sub-certificate and stamps the execution back onto its evidence, so planning and performing are one chain. Guided navigation suits the underspecified goal, the trap-prone workflow, and the human in the loop: anywhere the value of seeing the alternatives exceeds the cost of the extra turns.\n\n### The Session\n\nA guided session is server-held state: the derived tree, the policy under which it was built, the path taken, the steps recorded, accumulated cost, and any pending input request. Every recorded step carries enough to replay or audit the traversal: the choice made, the option's identity, the arguments bound, the parent position, the cost.\n\n```mermaid\nflowchart TB\n    o[\"options presented<br/>label, cost, viability, reason\"] -- \"choose\" --> r[\"step recorded<br/>no tool runs\"]\n    r -- \"prepared children\" --> o\n    r -- \"no prepared children\" --> x[\"tree grown at runtime<br/>type-compatible successors<br/>plus save-as-skill\"]\n    x -- \"successors found\" --> o\n    x -- \"no successors: terminal\" --> k\n    o -- \"choose passthrough\" --> n[\"input requested<br/>grounding attached\"]\n    n -- \"query supplied\" --> q[\"read-only query executes\"]\n    q -- \"error, same node\" --> n\n    q -- \"result folded in; today the session then completes\" --> k\n    o -- \"back\" --> b[\"pop last step<br/>recompute cost\"]\n    b --> o\n    o -- \"terminal or save\" --> k[\"compile to skill<br/>validate, sign, mint\"]\n```\n\n*The session as a state machine: every transition except the grounded query only records, so back is a pop and the terminal transition is the only one that produces a durable artifact.*\n\nPolicy participates at two altitudes. At tree construction, constraints (cost ceilings, step budgets, integration allowlists) shape what the planner may propose at all. During navigation, the same constraints are re-evaluated against the accumulated session and surfaced per option as viability verdicts with reasons, so the agent sees what its remaining budget permits, not only what exists.\n\n### Grounded Passthrough\n\nThe exception to plan-don't-execute is the grounded query path: when the navigator selects the expressive passthrough and supplies a query, the platform executes it, read-only by convention of the passthrough tools and not yet enforced by a gate, and folds the result into the session. The query was written against served grounding rather than a blank box, the result either advances the plan or returns an actionable error at the same node, and nothing with side effects has occurred.\n\n### From Traversal to Skill\n\nCompiling a session generalizes a demonstration into a program. The recorded steps replay into a declarative workflow, and each concrete argument value is classified: values that appeared in an earlier step's output become dataflow references, and every value the navigator supplied becomes a typed input hole. A query is one such hole, its whole text; finer-grained holes carved from inside a value (a quarter inside a query) are future work. Where an adapter chain can derive a hole's value from the workflow's other inputs, the hole is marked optional with its derivation; the rest are required inputs of the new skill. The assembled workflow is validated for cycle-freedom, type compatibility, and policy compliance, then minted with a signed certificate (see *Cognitive Trust Certificates: Verifiable Execution Proofs for Autonomous Systems*); a workflow that fails validation returns its errors and the composed plan rather than minting a broken skill.\n\n```mermaid\nflowchart LR\n    subgraph T[\"recorded traversal, in order\"]\n        direction TB\n        s1[\"step 1 · choose “opportunities”\"]\n        s2[\"step 2 · passthrough(query = “… Q1 … not renewal …”)\"]\n        s3[\"step 3 · shape(by = owner)\"]\n        s4[\"step 4 · deliver(step 2 result)\"]\n    end\n    subgraph C[\"classify each value\"]\n        direction TB\n        c1[\"“opportunities” → typed input\"]\n        c2[\"query text → one typed input<br/>the whole query, not quarter and exclusion\"]\n        c3[\"“owner” → typed input\"]\n        c4[\"step 2 result → dataflow edge\"]\n    end\n    s1 --> c1\n    s2 --> c2\n    s3 --> c3\n    s4 --> c4\n    K[\"skill(entity, query, by)<br/>validate: cycle-free · type-compatible · policy-conformant<br/>valid: signed CTC minted · invalid: errors and the composed plan returned\"]\n    c1 & c2 & c3 & c4 --> K\n```\n\n*From traversal to skill: every navigator-supplied value becomes a typed input, every earlier result becomes a dataflow edge, and only a workflow that validates is minted and signed.*\n\nNext quarter's run is a single call with a new query text.\n\nThe compounding matters more than the convenience. Guided sessions are the expensive, judgment-bearing path through the mesh; skills are their amortization. The organization's catalog accumulates certified workflows whose provenance is a recorded, replayable traversal, with the economics described in *Credit System: Economic Primitives for Autonomous Systems* (first run pays for discovery; every reuse is cheap).\n\n---\n\n## Worked Shape: A Trap-Prone Analytical Goal\n\nConsider \"average open-opportunity value by rep, this quarter, excluding renewals\" against a CRM. The autonomous ranking favors typed chains over fixed-shape reporting tools, which cannot express *excluding renewals* and will not say so. The guided presentation shows both: the typed chain and the flagged passthrough with its rationale. A navigator choosing the passthrough receives the grounding block (the org's opportunity fields, the dialect's aggregate restrictions), writes the query against real names, and executes it read-only. The result is folded into the session and the traversal can be compiled from there; continuation options after a grounded query (shaping, delivery) are the next step for the interface. The minted skill takes the query text as a typed input, carries its certificate, and next quarter's run is a single call.\n\nEvery element of that path — the surfaced passthrough, the attached grounding, the read-only execution, the exact backtrack when the first query errors, the parameterized skill — exists because the interaction is a dialog over a plan rather than a commitment to a ranking.\n\n---\n\n## Generalization Beyond Tool Discovery\n\nThe pattern of a server-side tree, an option-list interface, and choices recorded against policy is not specific to tool meshes; the platform reuses it for rule-driven surveys whose decision trees are compiled once at authoring time and presented with *zero* model involvement per interaction. Navigation is the governed alternative to both free generation and fixed forms.\n\n---\n\n## Comparison with Existing Approaches\n\n| Approach | Mesh visibility | Judgment locus | Side effects during exploration | Reusable artifact |\n|---|---|---|---|---|\n| Load tools into context, call in a loop | Partial, at full token cost | Agent, uninformed of paths | Agent-dependent | None |\n| Autonomous planning | Full (server-side) | Planner's ranking | None until execution | Plans / skills |\n| Guided navigation | Full (server-side), presented as options | Navigator, informed | None (read-only grounding excepted) | Certified skills from traversals |\n\n---\n\n## Limitations and Trade-Offs\n\n**Turns cost latency.** A dialog is round-trips; a well-shaped goal is answered faster by the autonomous interface. The guide earns its turns only where alternatives carry real information.\n\n**Presentation inherits the planner's recall.** Options come from the same candidate search that feeds autonomous planning; a tool the search misses is a tool the dialog never offers. Injection patches the known systematic gap (an expressive passthrough that recall found but ranking buried); a passthrough the search never returns is never injected.\n\n**Viability is advice at navigation time.** Constraints are enforced where plans are constructed and where skills are validated; during navigation they are surfaced as verdicts. A navigator can record a step past a blocked option; the accumulating plan will not survive compilation. The design accepts this, because mid-dialog enforcement would forbid exploring *why* a path is blocked.\n\n**Sessions are ephemeral by design.** Sessions live in a single-node in-memory table swept hourly; a traversal not compiled into a skill expires with its session. The bet is that durable value lives in the artifact, not the transcript.\n\n---\n\n## Future Directions\n\n### Learned Recommendation\n\nThe recommendation flag currently derives from goal-shape analysis. Sessions themselves are training signal: which options navigators choose, which paths reach compilation, which skills survive reuse. That closes the loop from navigation history to presentation order without surrendering the present-don't-rank contract.\n\n### Trees Over Skills\n\nThe tree today is built from tools; the catalog of minted skills is itself a navigable surface. Guided navigation over previously-compiled traversals (choose a skill, see its holes as the next options) would make the interface self-compounding.\n\n### Cross-Navigator Sessions\n\nA session is single-navigator today. The same recorded-step model supports handoff: an agent navigates to the judgment point, a human makes the sensitive choice, and the agent continues, with the traversal record attributing each step to its author.\n\n---\n\n*This document describes the conceptual architecture of guided navigation over tool meshes. Tree-construction heuristics, injection and recommendation rules, grounding assembly, and session internals are part of the operational implementation and are not specified here.*\n",
  "last_updated": "2026-08-01T00:00:00Z"
}