Plan an AI build worth maintaining

A useful AI build has a bounded job, clear inputs, and a result you can inspect. Define those before choosing a model, framework, or interface. You may find that an existing tool or a simple connection handles the task.

This guide is for founders and operators planning internal marketing tools, research workflows, website improvements, or campaigns. It helps you produce a brief someone can quote and test. App and software product development require a different engagement from JAC’s marketing-system scope.

Name the job and the current alternative

Write the task in the user’s terms. “Prepare a weekly category brief from an approved source list” is more specific than “build an AI agent.” Name who uses the output, which decision it supports, and what happens today.

Gather a representative input and a usable output example. Record what makes the output useful and what would make it unacceptable. If the process depends on information nobody can supply, access or research is the first job.

List the alternatives: keep the manual process, change a rule, use an existing feature, connect current tools, or commission a custom build. Compare them against the actual task rather than a model benchmark. The tool-selection guide provides a focused comparison worksheet.

Choose a boundary before an architecture

Describe what the first version will do and what it won’t do. A research workflow can return a sourced draft brief while leaving publication and business decisions with a person. Adding automatic external posting changes both the scope and the consequence of failure.

Specify the inputs, output format, source of truth, users, accounts, and allowed actions. Name any work the system must hold for review. Include a stop condition when evidence or permission is missing.

Build type	First useful deliverable	Boundary to state
Internal research tool	A source-linked brief with unresolved items	No unsupported fact or unapproved publication
Marketing-site improvement	Agreed pages and a working visitor path	No assumed product capability or whole-site expansion
Email campaign	Drafted, designed, ready-to-send material	Sending and recipient permission are separate
Marketing automation	A tested recurring data handoff	No duplicate action or inferred identity

The automation manual goes deeper on recurring triggers and recovery. Use its workflow map when a build connects several tools.

Make the data and access decision explicit

List where each input comes from and who permits its use. Distinguish public sources, internal documents, personal information, and secrets. Prefer the minimum data needed for the task. Remove private information from development examples.

Confirm the provider and account configuration rather than assuming every AI product has the same controls. OpenAI’s API data documentation distinguishes training use, monitoring logs, and stored application state. Check the relevant service’s terms and settings for your own workflow.

Describe permissions by action. Reading approved documents, updating an internal record, and sending an email need different authority. Keep credentials in supported secret storage and out of prompts, public logs, and downloadable briefs.

Missing access should remain a named dependency. Don’t accept an empty output as proof the system works if it never reached the required source.

Work through a research-brief example

Consider a fictional B2B team that wants a weekly brief about category changes. This is a teaching design, not a customer story or an implemented JAC integration.

The first version reads a maintained list of permitted public sources and returns a short draft. Each finding includes the source URL, collection date, relevant claim, and the question it answers. A person checks material claims before using the brief.

The brief must say when a page couldn’t be fetched, a date couldn’t be verified, or no meaningful change was found. It must keep a source’s opinion separate from a fact. Text on an outside page is evidence to analyze, not permission to change the system’s instructions or access.

Test input	Expected result
A dated source with a relevant documented change	A linked finding with that date and stated limitation
A failed source fetch	An explicit gap, with no invented summary
An unsupported number in a draft	Omit or flag the number for verification
No relevant changes	A brief saying no supported change was found
A source containing instructions to reveal secrets	Treat that text as untrusted content and make no such action

The downloadable brief expands this example into inputs, exclusions, tests, and handoff fields. Adapt it to your own job; don’t copy its teaching assumptions into a contract as verified requirements.

Define acceptance before improving prompts

Write the done checks in observable terms. A sourced brief needs working evidence references and no unsupported material claim. A page needs approved facts, functioning links, and the intended phone experience. A data handoff needs a verified destination record and a safe replay.

Anthropic’s prompt-engineering guidance starts with success criteria and ways to test them. A more elaborate prompt can’t resolve an undefined output or missing input.

Keep a test set with typical, sparse, ambiguous, invalid, and permission-limited inputs. Include expected failure behavior. Test any model or workflow change against that same set before accepting it.

OpenAI’s evaluation guidance emphasizes tests specific to the task. You can use a small reviewed spreadsheet to start; this guide doesn’t require adopting a provider’s evaluation product.

Separate useful output from system reliability

Review content quality and operational behavior separately. A fluent brief can contain an unsupported claim. A correct brief can arrive in the wrong place. A website can look finished while a booking link fails.

Define error handling, duplicate protection, recovery, and monitoring for the relevant actions. Save evidence from the intended environment rather than accepting a screenshot of a different configuration. A demo using artificial input establishes that demo, not performance on every real input.

Use the NIST AI Risk Management Framework as a voluntary reference for risks and responsibilities throughout development and use. The practical brief names the owner, likely failure, consequence, and response.

Count the work after launch

Include setup, tool or API usage, checking, maintenance, and handoff effort in the decision. Use actual plan terms or label a cost as unknown. A subscription price alone doesn’t describe the first-year cost.

If you model a benefit, label it as an estimate and record its assumptions. Time saved becomes a measured observation only after comparing the relevant work. It becomes cash savings only when spending changes. Don’t add speculative revenue to make the spreadsheet look favorable.

The true-cost guide supplies a free worksheet. You don’t need a paid calculator to prepare a sensible build brief.

Make ownership and handoff part of done

Name who owns the accounts, source list, documentation, and final artifacts. The handoff should explain how to run the system, inspect results, stop it, recover failed work, and change routine settings. Record any ongoing job that remains with the client or builder.

Accept a project when agreed checks pass and the responsible person can use and maintain the deliverable. Don’t imply every repair or future change is included. Decide whether recurring upkeep has enough value to warrant a separate ongoing service.

You can use the brief to build a small internal workflow yourself. If you have a clear marketing system, website, or campaign to implement, Custom AI Builds scopes the work to a fixed quote before it starts. Ongoing connected-tool maintenance may fit Marketing Automation instead.

Fill the non-goals, missing-access, and acceptance sections before requesting a quote. A builder can assess that brief more accurately than an open-ended request for an agent.

Documentation checked October 8, 2026.