Plan a workflow with the HtAG Use Case Builder

Turn a workflow idea into a plan you can review before building. The HtAG Use Case Builder maps your description to HtAG capabilities, proposes approaches and prepares a starter pack for the approach you choose.

The flow has three stages: Describe → Review → Artifacts. Start with a narrow task, check the proposed endpoint chain, then take the resulting instructions into your development tools.

1. Describe the job, not just the dataset

In What do you want to build?, explain who will use the result, what decision or task it supports, the geography or property scope and what you want the output to show. The input needs at least 15 characters, but a useful brief contains more than a topic name.

Include constraints that matter: property type, reporting period, handling of missing values, request bounds, caching and an acceptable budget. The builder can make a more focused plan when those choices are explicit.

An example brief

Build an internal suburb comparison dashboard for an Australian property team. Compare Richmond VIC with Carlton VIC for houses using current market context. Show the reporting period and missing data clearly. Start with two localities and no automatic pagination. Plan costs before API calls and cache the retrieved snapshot.

Replace these places and requirements with your own. This brief describes an intended workflow; it does not supply verified locality identifiers or grant permission to retrieve unlimited data.

2. Choose the target

The target choices are AI Agent for Claude, Cursor, Codex or Claude Code; Web App for a site or customer dashboard; Integration for a backend, CRM, batch or system-to-system workflow; and I’m not sure if you want help choosing.

Choose the closest target, then press Show me how →. The builder maps the API catalogue, MCP servers and micro-agent registry to your description and drafts a plan. Keep the tab open: the interface says closing it cancels the run. It displays a typical wait of 1–2 minutes for this stage, rather than promising an instant result.

3. Review the recommended and alternative approaches

The Review stage displays a recommended approach and other approaches. Each can have a different level of detail or a different combination of capabilities. Use Refine the description if the proposed workflow does not match your intent.

Expand Endpoint chain to inspect the sequence. The cards explain the endpoint, why it is included, proposed inputs and expected outputs. Expand Joins, pitfalls, next steps to see how identifiers connect steps, what needs care and what you could add later.

For the two-suburb example, the builder proposed resolving each suburb with /reference/locality before retrieving market context. A simpler alternative focused on those locality lookups and /markets/summary; richer alternatives added scores, fundamentals or a future spatial drilldown. Your generated choices will depend on your brief.

4. Check the plan against the live contract and pricing

Treat the generated plan as a starting point to verify. Open the API reference and confirm parameter names, supported selections, result fields, authentication and limits for each endpoint. Check the current rate card for actual tiers and billing units.

• Do locality lookups return the identifiers later steps require?
• Are property type, bedrooms and reporting context consistent?
• Are missing values kept distinct from zero?
• Does each call have a row or unit limit where supported?
• Is a repeated endpoint an optional refresh, or a required step?
• Is there a cost plan for the initial run and later refreshes?

The generated tier labels and proposed request syntax should be verified before execution. A recommended approach does not automatically make every suggested call necessary. Choose the smallest chain that solves your task, then deliberately add detail.

5. Choose an approach and generate the starter pack

Press Use this approach on the option you want. The Artifacts stage assembles a focused SKILL, an agent prompt and an OpenAPI manifest, with installation snippets tailored to the selected workflow. The interface again asks you to keep the tab open while the build runs.

A SKILL provides workflow instructions for an assistant; an agent prompt gives it the specific task and operating rules; the manifest describes the API operations selected for the build. Review the generated material before putting it into an assistant or application.

Use Pick a different approach when you want to revisit the selection, or Build another use case for a different task once those controls are available.

6. Test one small request before wiring the full workflow

Take the first operation into the Playground. Confirm its parameters, returned identifiers and data shape with a bounded request. Our Playground guide walks through a small locality lookup.

For an AI Agent target, use the three-server MCP setup guide and confirm which servers the generated workflow needs. For a Web App or Integration target, use the API setup guide and keep credentials in the appropriate secure backend or secret store.

Building a starter pack is not the same as executing its API or research-agent calls. Check funding, rates and the proposed workload before running those calls. Apply the cost-management guide, including actual billing-header tracking after execution.

7. Make the first version easy to inspect

For a comparison dashboard, start with two confirmed locality records and a clear current snapshot. Keep the geography, property selection, reporting period and retrieval time visible. Cache the response appropriately and add new endpoints only when a user task calls for them.

For a CRM integration, define what identifies a record and where a person confirms an address match. For an AI workflow, define the question, allowed tools and when it must stop to ask about extra cost or a wider scope.

Your builder checklist

• Your brief names the user, task, scope and desired output.
• The selected target matches where you intend to build.
• You reviewed the endpoint chain, joins and pitfalls.
• Live API contracts and prices were checked independently.
• The starter pack is reviewed before use.
• One bounded request is verified before the full workflow runs.

Open the Use Case Builder or return to the Get started collection.