A starting source · shared freely · August 2026
Ask It. Build It.
A technical reference and plain-language guide to how AI systems are actually used — hosted assistants, agentic coding environments, and programmatic access through APIs — and the verification duties that scale with consequence.
This guide comes out of ongoing whiteboard working sessions with a trusted circle of law students and attorneys, where the working rule is shared ideas rather than instruction. It is offered here as a starting source, not a final word. Product names, plan limits, and prices change quickly; the technical distinctions are the stable part.
Contents
2 · Ask It
3 · Build It
4 · Embed It
5 · AI is not automation
6 · Legal professional use
7 · Translation dictionary
8 · Reusable templates
9 · Authorities and sources
1The Complete Map
Three access modes, one stack of capabilities.
You communicate directly with the system and receive an answer, analysis, or document.
You give the system a bounded workspace, tools, and a result to create or change.
| Payment model | What it means |
|---|---|
| Subscription | A recurring fee for access to a hosted application or seat, subject to plan features, usage allowances, rate limits, and acceptable-use rules. “Fixed price” does not always mean unlimited use. |
| Metered | A variable charge based on measured consumption. AI APIs commonly meter input tokens, output tokens, cached context, tool calls, searches, runtime, storage, or a combination. |
| The stack | A hosted assistant can call APIs behind the scenes. A coding agent can write and test the code that calls APIs. An API-powered application can itself contain a chat interface, a coding agent, an automated workflow, or all three. |
2Ask It — Hosted Assistants and Direct Prompting
A hosted AI assistant is a vendor-managed application that accepts natural-language and multimodal input, assembles a working context, invokes one or more models and tools, and returns text, images, files, code, or analysis through a conversational interface.
What happens technically: the application receives your prompt, files, and history; selects or routes to a model, possibly with tools such as search or code execution; the model performs inference — computing a probable and useful output from the supplied context; the result returns in human-facing form; you review, correct, refine, and verify.
| The four questions | What each means | Say it out loud |
|---|---|---|
| 1 · Context — what should it know? | The information available for the current inference: instructions, facts, documents, prior messages, retrieved sources. Bounded by a context window measured in tokens. | “What background, facts, documents, and role does the system need before it can do the job well?” |
| 2 · Task — what should it do? | The intended cognitive operation: explain, compare, extract, classify, critique, calculate, draft, recommend. | “What exact job am I assigning?” |
| 3 · Constraints — what rules must it follow? | Scope, sources, exclusions, governing law, audience, style, risk controls, prohibited behavior. They reduce ambiguity but do not guarantee correctness. | “What boundaries should control the work?” |
| 4 · Output — what should the result look like? | Format, structure, level of detail, citation method, file type, acceptance criteria. | “What does a useful answer look like when it comes back?” |
Verify according to consequence
Accuracy is not one universal threshold; the acceptable error rate depends on what the output is for. Brainstorming tolerates roughness. Legal authority, deadlines, client facts, and filed representations require direct verification.
| Example | Why the percentage is not the whole question |
|---|---|
| 1,000 extracted facts at 99.9% | Statistically, about one error remains. |
| 10,000 citations at 99.9% | Statistically, about ten errors remain. |
| One dispositive case | A single fabricated, overruled, or misread authority can materially damage the work even if every other item is correct. |
3Build It — Agentic Coding Environments
A coding agent is an AI-enabled software agent that can inspect a project workspace, edit multiple files, execute commands, run tests, read logs, and iterate toward a specified result. Its practical capability comes from the combination of a model, tools, workspace access, execution, memory or state, and a control loop.
| The four questions | What each means | Say it out loud |
|---|---|---|
| 1 · What can it see and touch? | The execution scope: working directory, files, databases, network access, tools, credentials, read and write permissions. A sandbox and approval policy enforce boundaries. | “What am I allowing it to read, change, run, or reach?” |
| 2 · What do I want it to make or do? | The functional specification: desired behavior, inputs, processing steps, edge cases, acceptance criteria. | “What should the finished thing accomplish, step by step?” |
| 3 · What is it allowed to do and not do? | Guardrails and least-privilege controls: source restrictions, forbidden commands, protected originals, confidentiality boundaries, approval requirements, stop conditions. | “What boundaries must it never cross, even if crossing them would be easier?” |
| 4 · What does done look like? | The definition of done: working output, passing tests, required formats, source map, run log, instructions, reproducibility, human acceptance. | “What exact files, evidence, tests, and instructions must exist before I call it complete?” |
Why task decomposition matters
A complex result should not be treated as one giant generation. It decomposes into stages with intermediate artifacts and checks: preserve and inventory the sources; extract text and metadata repeatably; apply the defined checklist or rule set; generate structured findings with source references; run tests and quality checks; render the outputs; inspect the final artifacts and record remaining limitations.
The agent does not merely produce a confident final memo. It leaves a chain of inspectable work products that can be reviewed, rerun, corrected, and compared.
4Embed It — APIs as Standardized Access
An application programming interface is a defined contract that allows one software system to request data or operations from another. In a model API, client software sends an authenticated request containing a model selection, instructions, inputs, tools, and parameters; the service performs inference and returns a structured response the client can display, store, validate, or use in another operation.
The electricity analogy, stated precisely
| Electric system | AI / software system |
|---|---|
| Electric generating capacity | Model or service capability |
| Outlet or standardized connection | API endpoint and protocol |
| Wiring and control circuitry | Code, SDKs, schemas, and authentication |
| Appliance or factory machine | Application, tool, or workflow |
| Electric meter | Usage accounting: tokens, requests, tool charges |
| Timer, switch, relay, control system | Automation, triggers, orchestration, approvals |
| The three questions | What each means | Say it out loud |
|---|---|---|
| 1 · What can I access? | API discovery and capability analysis: available services, endpoints, data coverage, operations, authentication, schemas, pricing, licensing, retention, rate limits, reliability. | “What useful data or capability is available through a connection?” |
| 2 · Can I make it talk to X? | Systems integration: whether two systems can authenticate, exchange compatible data, map identifiers and fields, handle errors, and satisfy security and legal requirements. | “Can I connect this source or capability to the tool I already use?” |
| 3 · What can I make it do? | Workflow and application design: triggers, input collection, model or service calls, validation, human approval, downstream actions, storage, notifications, monitoring. | “Once they are connected, what useful process can I create?” |
Metered usage, simply: API cost = input usage + output usage + tool and service charges + storage or runtime charges. Cost control means choosing an appropriate model, reducing unnecessary context, caching repeated material, using structured outputs, batching work, setting spend limits, and routing simple tasks to cheaper or local components.
Local and hybrid systems: a hosted API runs on a vendor's infrastructure under the vendor's terms. Local inference runs model weights on hardware you control — no vendor token charge, but hardware, electricity, maintenance, licensing, and capability tradeoffs. A locally running model can expose a local API to other local software. Sensitive or routine work can remain local while higher-capability tasks call hosted APIs; the best design depends on data risk, required quality, latency, cost, and maintenance capacity.
A legal example — authority and rulemaking monitor: official-source APIs provide new opinions, Federal Register documents, dockets, and bills; the application stores the original source and retrieval metadata; a model classifies relevance and proposes links to existing matters; the system requires source verification and human approval before anything becomes legal analysis; approved findings update a matter dashboard or draft memorandum. FederalRegister.gov, Regulations.gov, Congress.gov, and CourtListener all expose public endpoints — coverage and terms must be checked per project.
5AI Is Not Automation
Intelligence, connection, triggers, and orchestration are separate layers. AI supplies probabilistic analysis or generation. Automation runs defined steps because a schedule, event, rule, or user action triggered it. An API is a connection — it does not decide when to run. An agentic workflow combines a model with instructions, tools, state, iterative planning, guardrails, and stopping conditions. A human in the loop is a designed review point before consequential output is used.
| Type | Technical description | Normal language |
|---|---|---|
| Automation only | A deterministic schedule or rule executes without model inference. | “Every Friday at 5:00, send me this file.” |
| AI only | A person manually asks a model to perform a cognitive task. | “Read this file and tell me what looks unusual.” |
| AI plus automation | A trigger collects input, calls a model, validates the result, and performs a downstream step. | “Every Friday, analyze the file and alert me only if something unusual appears.” |
| Agentic workflow | The system may choose among tools and intermediate steps while remaining inside defined permissions and stop conditions. | “Review the new materials, gather the approved sources, run the checks, repair any failed output, and present the result for approval.” |
6Reliability and Legal Professional Use
The more consequential the work, the more explicit the controls.
A professional reliability stack: control the source set; separate retrieval from analysis — the model is not the source of the law or the record; require provenance for each material finding; validate structure with schemas and cross-checks rather than accepting free-form prose; current-check authority for negative treatment, amendments, and jurisdiction; review by consequence — a qualified reviewer approves legal conclusions, filings, and deadlines; preserve an audit trail of inputs, versions, outputs, corrections, and approvals.
Legal-source verification protocol
| Check | Required action |
|---|---|
| Existence | Open the cited authority or record item. Confirm it exists and is the document represented. |
| Proposition | Read the relevant text. Confirm it actually supports the stated proposition. |
| Pin cite | Confirm the precise page, paragraph, section, or record location. |
| Status | Check currentness, amendments, negative treatment, jurisdiction, and precedential weight. |
| Record fit | Confirm the legal proposition connects to the actual facts and procedural posture. |
| Final responsibility | The lawyer adopts the conclusion only after independent professional review. |
Confidentiality and access control: minimum necessary data and narrowest practical permissions; read-only access to originals, writes to separate output locations; understand the vendor's retention, training, sharing, deletion, and breach policies before disclosing protected information; protect API keys like passwords; separate matters so an agent cannot browse unrelated information; explicit approval gates for consequential actions; log enough to investigate errors and demonstrate supervision.
7Whiteboard Translation Dictionary
Technical language paired with the simplest accurate explanation.
| Ask It — term | Board language |
|---|---|
| Hosted AI assistant | A ready-made application where a person talks directly to AI. |
| Model | The computational system that produces the answer. |
| Prompt | The job instructions and material you give it. |
| Context | What it can consider while doing the current job. |
| Task | The exact job you want performed. |
| Constraint | A rule or boundary for the work. |
| Output specification | What the finished answer or file should look like. |
| Grounding | Making the answer rely on identified sources. |
| Hallucination | A confident-sounding answer that is unsupported or false. |
| Build It — term | Board language |
|---|---|
| Coding agent | AI that can work through files, code, tools, and steps — not just answer. |
| Workspace | The project area you let it work inside. |
| Read / write / network permission | What it may inspect; what it may change or create; what outside systems it may contact. |
| Sandbox | The fence around where it can act. |
| Specification | A precise description of what to build. |
| Acceptance criteria | The tests for whether the result is actually done. |
| Artifact | The tool, memo, PDF, spreadsheet, or other thing produced. |
| Audit trail | The record showing what happened and why. |
| Reproducibility | Enough preserved process and evidence to rerun and inspect the work. |
| Embed It — term | Board language |
|---|---|
| API | A standardized connection that lets software ask another system for data or work. |
| Endpoint | A specific connection for a specific operation. |
| Request / response | What the first system sends; what the second system sends back. |
| Authentication / API key | Proving the software is allowed to use the connection; the secret credential it uses. |
| JSON / schema / structured output | A machine-readable format; the agreed structure of the data; an answer forced into a predictable format. |
| Rate limit / latency | How much or how fast the service lets you use it; how long a result takes. |
| Webhook | One service notifying another that something happened. |
| Orchestration | The logic that coordinates the entire process. |
| Local inference / hybrid system | Running the model on hardware you control; using local and hosted capabilities together. |
8Reusable Templates
A · Direct assistant prompt
CONTEXT [Role, background, governing facts, documents, audience, and what to treat as authoritative.] TASK [The exact cognitive operation and objective.] CONSTRAINTS [Source limits, exclusions, governing law, confidentiality limits, uncertainty rules, prohibited assumptions.] OUTPUT [Structure, level of detail, citations, file type, and the definition of a useful result.]
B · Coding-agent build brief
PROJECT OBJECTIVE [The finished capability in one sentence.] WORKSPACE AND ACCESS [Folders, files, tools, network access, credentials, read/write boundaries, protected originals.] FUNCTIONAL REQUIREMENTS [Inputs, processing steps, outputs, edge cases, user workflow.] GUARDRAILS [Forbidden sources and actions, approval gates, confidentiality limits, stop conditions.] DEFINITION OF DONE [Required artifacts, formats, tests, source mapping, logs, documentation, reproducibility, known-limitations report.]
C · API discovery prompt
I want to create this outcome: [describe outcome]. Identify the systems, data sources, and capabilities that may have APIs. For each: available data or operations; authentication; coverage; format; rate limits; pricing; retention; licensing; reliability; legal or security constraints. Then propose the simplest architecture, a minimum viable prototype, a test plan, and the questions to answer before implementation. Distinguish verified facts from assumptions and cite official documentation for each service.
D · API integration brief
OUTCOME [What event should produce what result.] SOURCE SYSTEMS [APIs, databases, files, internal systems.] AUTHENTICATION AND SECRETS [How credentials are stored, rotated, and kept out of logs and source control.] DATA FLOW [Trigger → retrieve → normalize → model/service call → validate → approve → act → log.] OUTPUT SCHEMA [Required fields, types, source identifiers, uncertainty flags, error states.] RELIABILITY [Retries, timeouts, rate-limit handling, monitoring, tests, fallbacks.] LEGAL AND SECURITY BOUNDARIES [Permitted data, retention, matter separation, human approval, audit logs, prohibited actions.]
E · Legal AI quality-control checklist
- The source exists and was opened.
- The source is authoritative for the proposition.
- The quoted or summarized language is accurate; the pin cite is correct.
- The authority is current with the correct precedential weight.
- The factual statement is supported by the actual record.
- No prohibited source was used; no protected information disclosed.
- The output identifies uncertainty instead of concealing it.
- A qualified human reviewed the result before consequential use.
- The inputs, output, corrections, approval, and final artifact were preserved.
9Authorities and Technical Sources
Legal authorities. ABA Comm. on Ethics & Prof'l Responsibility, Formal Op. 512 (2024) · Fla. Bar Ethics Op. 24-1 (2024) · Mata v. Avianca, Inc., 678 F. Supp. 3d 443, 461–66 (S.D.N.Y. 2023) · Fed. R. Civ. P. 11(b), 26(g).
Vendor documentation (as of August 2026): OpenAI platform and Codex documentation; Anthropic Claude, Claude Code, and API documentation.
Illustrative legal and government data APIs: FederalRegister.gov · Regulations.gov · Congress.gov · CourtListener. Coverage, access rules, and terms must be checked for the specific project.
Currentness note: vendors frequently change model names, plan limits, pricing, interfaces, and tools. The conceptual distinctions in this guide remain valid even when a brand or plan changes.
This guide is a starting source, not a final word. It comes out of whiteboard sessions where the working rule is shared ideas rather than instruction — every discussion has sharpened it, and the next one will too.
If anything here raises a question, or you see it differently, reach out on LinkedIn. I don't know what I don't know, and new questions are how this gets better. It's the people we meet.