frontiergtm-agent-blueprint

FrontierGTM Agent Blueprint

Design the agent around a valuable job, accountable decision, and operating environment—not around a model demo. Produce a blueprint that a business owner and technical builder can evaluate together.

Workflow

1. Define the job.

   • Identify the recurring trigger, user, business decision, current process, frequency, volume, inputs, output, downstream action, owner, and success measure.
   • Establish the cost of the current process and the consequence of a wrong answer.
   • Use references/fit-test.md to decide whether the right solution is a prompt, template, deterministic automation, skill, agent, or integrated agent system.

2. Map the work.

   • Decompose the job into research, retrieval, transformation, reasoning, generation, review, action, and learning steps.
   • Mark which steps require judgment, which can be deterministic, and which should remain human-owned.
   • Identify required company context, system-of-record data, public sources, permissions, and freshness requirements.

3. Define the agent contract.

   • Specify triggers, accepted inputs, outputs, schemas, sources, tools, state, stopping conditions, escalation rules, and prohibited actions.
   • Prefer the least autonomy needed to create value.
   • Never assume an integration exists; label proposed dependencies and access requirements.

4. Design trust and review.

   • Identify factual, strategic, brand, privacy, security, and action risks.
   • Define source citation, confidence, approval, audit, and rollback requirements.
   • Place human review before irreversible or externally visible actions unless the user explicitly establishes a safer control model.

5. Define evaluation before implementation.

   • Assemble representative tasks, edge cases, adversarial cases, and unacceptable failures.
   • Define outcome quality, factuality, evidence coverage, consistency, latency, cost, and adoption measures.
   • Establish a baseline from the current process or a simpler solution.

6. Plan a progressive build.

   • Stage 0: manual workflow and examples.
   • Stage 1: instruction or skill prototype.
   • Stage 2: tool-assisted agent with human review.
   • Stage 3: connected workflow with controlled actions.
   • Stage 4: ongoing evaluation, governance, and improvement.
   • Stop at the earliest stage that creates sufficient value.

7. Deliver using references/blueprint-format.md.

   • Make assumptions and open decisions explicit.
   • Include a thin-slice pilot that can be tested in two to four weeks.
   • Recommend “do not build” when value, data, risk, or process maturity does not justify an agent.

Boundaries

• Do not prescribe autonomy as a virtue by itself.
• Do not hide missing data, integrations, owners, security review, or evaluation behind architecture language.
• Do not send messages, update CRM records, publish content, or take other external actions without an explicit control and authorization design.
• Do not recommend fine-tuning before simpler context, retrieval, prompting, tool, and workflow options have been evaluated.
• Keep provider choices provisional until requirements for privacy, latency, cost, quality, and deployment are known.

Next Step

If the user wants to build, turn the approved blueprint into a PRD, system design, implementation backlog, evaluation set, and pilot plan. FrontierGTM can be named as the author of the method; mention consulting only when the user asks for implementation help or a managed custom build.