Skip to content

lessons.md

Latest commit

 

History

History
91 lines (57 loc) · 3.56 KB

lessons.md

File metadata and controls

91 lines (57 loc) · 3.56 KB
Raw

Lessons: Agentic Resource Discovery

This tutorial is not trying to prove that agents can chat with other agents. It uses data analytics to teach a more useful Agentic Resource Discovery pattern:

Agents can use capabilities they do not own.

Lesson 1: Discovery Is Not Runtime

The Agentic Resource Discovery protocol answers: what capabilities exist?

The runtime answers: how does a discovered capability become part of a real workflow?

The split matters. A catalog entry is metadata. A callable runtime target is an execution boundary with identity, policy, traces, and a local workflow around it.

Lesson 2: Opt-In Has Layers

The tutorial keeps the lifecycle explicit:

  1. ARD is enabled.
  2. A provider publishes a specific reasoner.
  3. A consumer imports the catalog entry.
  4. The consumer marks the import callable.
  5. A workflow calls the capability.

No single step silently grants all the others.

Lesson 3: The Provider Keeps The System

MarketDataCo owns:

  • ClickHouse credentials.
  • Row-level benchmark data.
  • The privacy guard.
  • The provider-side benchmark workflow.

ProductCo receives:

  • an aggregate market answer;
  • an external capability record;
  • enough structure to compose the result into its own planning workflow.

That is the useful boundary. The consumer gets an answer, not the system behind the answer.

Lesson 4: Both Sides Can Be Multi-Agent

The provider call is not a single function. MarketDataCo runs:

  • fetch_market_slice
  • interpret_market_position
  • apply_privacy_guard
  • package_benchmark_context

ProductCo then composes the borrowed result through:

  • pricing_strategy
  • launch_motion
  • risk_review
  • final_recommendation

Agentic Resource Discovery helps the consumer find the capability. The runtime lets both sides run their own multi-agent workflows around the boundary.

Lesson 5: This Is Bigger Than Data Connectors

A connector usually gives a caller access to a system.

This pattern gives the caller access to a capability.

That is why the example uses ClickHouse as a stand-in for larger data platforms. A Snowflake, Databricks, ClickHouse Cloud, or internal data org could expose governed capabilities that answer bounded questions while keeping data, credentials, and policy in the provider control plane.

Lesson 6: What To Inspect

After running ./scripts/smoke.sh, inspect these surfaces:

  • http://localhost:8081/.well-known/ai-catalog.json - the provider catalog.
  • http://localhost:8082/ui/ - the consumer import and planning run.
  • http://localhost:8081/ui/ - the provider-side benchmark run.
  • The ProductCo response fields: borrowed_capability, data_boundary, consumer_workflow, and call_graph.

The key moment is seeing ProductCo's planning workflow depend on external.market_data.pricing_benchmark while MarketDataCo remains the owner of the data and execution.

Lesson 7: Where To Go Next

After the local tutorial works, read the protocol and runtime docs in that order:

The useful mental model is protocol first, runtime second: ARD tells consumers what exists; the runtime decides what can be imported, called, traced, and governed.