Click Agent

Turning a hot agent tool into a Hood2 execution graph

When a new agent tool becomes popular, the first question is usually "how do I plug it into my agent?"

A second question is often more useful:

What part of this tool is actually a repeatable procedure?

Many agent tools are not magic. They wrap a known path:

• resolve an input
• check local context
• call an API or script
• filter the result
• verify that the result fits the task
• return a compact summary to the model

That path is a good candidate for a Hood2 execution graph.

Example: versioned docs retrieval

Take a Context7-style documentation tool as the example. Context7 is useful because it addresses a real agent problem: the model may know an old API shape, while the local project uses a newer library version.

The tool idea is simple: fetch current, version-specific documentation and put it into the agent context. See Context7 and the broader Model Context Protocol server ecosystem for the general pattern.

But the workflow around that tool is not only "call docs API." It has structure:

Context7 Versioned Docs Retrieval
  Resolve Target
  Select Scope
  Fetch And Reduce
  Verify Fit

Each child node represents a deterministic part of the work.

The conversion

A Hood2 graph separates the repeatable part from the model-judgment part.

The repeatable part becomes commands:

• resolve_library_id
• select_version_and_topic
• fetch_docs
• extract_snippet_pack
• verify_context_fit

The graph also records status checks:

• library_resolved
• version_topic_selected
• docs_fetched
• snippet_pack_ready

And it records the condition that says when the graph can hand useful context to the agent:

ready_for_agent_context =
  library_resolved != null
  and version_topic_selected != null
  and snippet_pack_ready != null

The sequence becomes explicit:

retrieve_current_docs:
  resolve_library_id
  select_version_and_topic
  fetch_docs
  extract_snippet_pack
  verify_context_fit

This is still a tool. The difference is that the tool is no longer an opaque function name buried inside an agent prompt. It is a visible graph with commands, status, conditions, and a sequence.

What the model still does

The model still matters. It should handle the parts that are not deterministic:

• understand which library the user actually means
• decide whether the fetched snippets answer the coding question
• explain tradeoffs when docs are incomplete or conflicting
• suggest when a missing branch should be added to the graph

The goal is not "no model." The goal is to stop spending model context on the same mechanical procedure every time.

Why this helps

For a one-off task, a prompt and a tool call may be enough.

For repeated work, the graph has advantages:

• It reduces repeated token/context use because known procedure lives as graph state.
• It is inspectable, so a user can see what the agent is about to do.
• It is testable, because commands and status checks can be run directly.
• It is refactorable, because common steps can move into shared graph nodes.
• It is safer, because mutation points and review points become explicit.

The same pattern works beyond docs retrieval:

• GitHub issue triage
• Playwright browser workflows
• n8n self-hosted workflow checks
• database inspection
• cloud resource readiness checks
• shell scripts that teams keep re-explaining in runbooks

The Click Agent demo

Click Agent now has an optional Tool Graphs demo project:

agent_tool_graphs

It is not meant to replace a user's private Knowledge project. Private team procedures still belong in Knowledge or in a smaller dedicated Hood2 project.

The global atlas is a demo: take common agent tools and skills, identify the deterministic workflow inside them, and turn that workflow into visible Hood2 graph structure.

That is the product direction: agents should not only have tools. They should have inspectable execution graphs for the parts of tool use that are already known.