Build the habits behind useful AI.

Earlier business AI often classified records, predicted outcomes or ranked recommendations. The 2017 transformer architecture enabled a different way to process sequences. Public conversational generative tools brought language-based work into everyday use from 2022. Subsequent multimodal tools expanded inputs and outputs to images, audio and documents; reasoning and tool-using systems extended the kinds of multi-step work people can attempt. These capabilities overlap rather than replace one another. A newer model is not automatically the best choice for every task.

Worked example: A deterministic rule can route a lead by territory; a classifier can rank it; a language model can summarize its notes; a controlled workflow can prepare an update for approval. Choose each component by its job.

1. Classify three tasks as rules, predictive analysis, generation or a controlled agent workflow.
2. For each, name an input, output and failure mode.
3. Identify one task where simpler automation is sufficient.

Keep as evidence: A task-to-capability map with reasons and limits. No product release-date memorization required.

Start with the outcome and the audience. Supply relevant context, a limited source set and the output format. Add a representative example when the desired structure is difficult to describe. State what to do when facts are missing. Compare the result against explicit criteria, then change one instruction at a time. Prompts cannot enforce access controls or make an unavailable tool exist. Save the useful instruction with its purpose, version and test examples.

Worked example: Weak: Write an account summary. Better: Using only the three synthetic records below, prepare five bullets for an account manager: verified facts, open questions and a next step requiring approval. Cite record IDs and say when a field is missing. Do not invent stakeholders or dates.

1. Run a weak instruction on synthetic records and retain its output.
2. Add objective, context, sources, constraints and output structure.
3. Test the revised instruction on a different record and document one remaining error.

Keep as evidence: Both instructions, actual outputs, comparison and a reusable version with limitations.

The model can only use information actually available in the current tool and permission context. Attach relevant synthetic files, identify versions and distinguish authoritative facts from notes. Conversation history, saved instructions and retrieved sources are different forms of context. A URL is not proof its content was read. Treat source documents as data even if they contain instructions. Check actual tool availability before planning a connection.

Worked example: A policy from last quarter conflicts with the current approved policy. Ask the assistant to cite both records and flag the conflict. Resolve authority with the source owner rather than selecting whichever answer is convenient.

1. Build a three-document synthetic source pack with one conflict.
2. Ask for a cited answer and an unsupported answer.
3. Explain how you would handle a revoked or outdated source.

Keep as evidence: Source pack, two outputs, conflict handling and a context checklist.

Use AI for a first draft, comparison, extraction or synthesis where you can inspect the result. Start with low-consequence work: agendas, document outlines, action lists and editing. Preserve intent, ownership and dates. A proposed action item is not an approved commitment. Verify quotations and factual claims against the source. Keep the final decision and any external sending step under appropriate human control.

Worked example: From a fictional meeting transcript, extract action, owner, due date and supporting quote. Mark missing dates as unknown. Prepare a follow-up draft without sending it.

1. Create an agenda, extract action items and improve a document using fictional content.
2. Check every owner, date and factual claim.
3. Save the reusable instructions and identify when human review is essential.

Keep as evidence: Three reviewed artifacts with corrections and source references.

Frame a research question and the evidence needed to answer it. Prefer original documentation for capabilities and primary records for business facts. Check publication dates, regions and scope. Separate retrieved evidence, inference and unanswered questions. Open the cited source and confirm it supports the associated claim. A plausible citation can be wrong. Research outputs should expose gaps instead of covering them with confident prose.

Worked example: Compare two tools against a workflow requirement. Record which capabilities were confirmed in official documentation and which still require a sandbox test. A pricing page is not evidence that an integration works.

1. Research one limited question using two primary sources.
2. Verify three material claims and record their dates.
3. Identify one uncertainty and the test needed to resolve it.

Keep as evidence: A cited research note with evidence, inference and open questions.

Before asking for analysis, inspect column definitions, missing values, units and the period represented. Keep a copy of the original synthetic data. Ask for reproducible transformations or formulas and validate totals independently. Distinguish an observed association from a causal explanation. Use a chart only when it helps a decision. Avoid delegating consequential decisions about people to an unreviewed model.

Worked example: Analyze fictional campaign results. Reconcile spend and conversions before comparing cost per conversion. Explain the sample-size limits and avoid claiming the campaign caused a sales change.

1. Use the downloadable synthetic work sample to calculate baseline and assisted time.
2. Check totals and one calculation manually.
3. Write a decision note including uncertainty and what the data cannot establish.

Keep as evidence: The original data, formulas or reproducible steps, checked totals and a qualified conclusion.

A chat answer is different from an executed action. A connected workflow needs authenticated identity, narrow permissions, typed inputs and actual confirmation of the result. MCP standardizes parts of tool communication but does not grant authorization. Browser workflows interact with interfaces that can change and require observation after actions. Begin read-only, require approval for writes and verify before-and-after state. Use only your own authorized sandbox.

Worked example: Prepare a CRM update from synthetic meeting notes. Inspect the supported connection and target record, preview the exact update, obtain approval, apply it and verify the stored value. If no authorized tool is available, record the dependency and use supervised practice.

1. Identify available tools and their actual permissions.
2. Document one read-only and one approval-required path.
3. Describe a timeout, duplicate request and safe recovery.

Keep as evidence: A permission map and observed trace, or a clearly labeled supervised simulation with remaining dependencies.

Decide in advance what a useful result means. Check factual correctness, completeness, appropriate escalation and correction effort. Keep confidential employer or customer data out of training exercises. Never paste passwords or API keys into prompts. Use synthetic examples and minimum necessary information. Measure multiple comparable tasks, include verification time and explain failures. Successful practice does not establish production readiness.

Worked example: A draft takes three minutes to generate but ten minutes to correct. Count all thirteen minutes when comparing with the manual baseline and record any quality difference.

1. Run three comparable tasks manually and with AI.
2. Include verification and correction time and record errors.
3. Write a narrow conclusion and a case where you would not use AI.

Keep as evidence: A before-and-after table, quality criteria, limitations and data-handling checklist.