# Free AI Tutorials and Step-by-Step Workflow Guides
Canonical source: [https://isaiuseful.com/guides](https://isaiuseful.com/guides)
From evidence to a working system
Choose a deliverable, keep authority narrow and decide what success means before the model starts. These guides are designed to survive changes in vendors, models and hardware.
- [Find a guide](#chooser)
- [Compare implementation options](#paths)
- [Browse tools](https://isaiuseful.com/tools.html.md)
**14**
complete starter workflows
FOUNDATIONS TO AGENT SYSTEMS
**10**
supervised runs before expansion
MEASURE BEFORE TRUST
**0**
automatic high-impact actions
DRAFT-ONLY BY DEFAULT
Guide selector
## Which AI tutorial should you start with?
Follow 01–14 as a progressive learning path, or filter by the work, risk and time you have. Later guides reuse the contracts, evaluation and controls introduced earlier.
14 guides match
01
Produce a cited research brief
Turn a decision question into a short report whose important claims can be checked.
25 min
Beginner
Cloud
**Deliverable:** a one-page brief, a claim-to-source table and a short list of unresolved questions.
### Build it
1. 01 **Write the research contract.** Name the decision, scope, date cutoff, trusted source types, exclusions and required output.
2. 02 **Gather primary sources first.** Ask the agent to prefer official data, papers and original documentation, then identify disagreements instead of averaging them away.
3. 03 **Require a claim table.** For each consequential claim, record the source, publication date and whether the source directly supports it.
4. 04 **Verify before sharing.** Open the original source behind the five claims most likely to change the decision. Remove or qualify anything unsupported.
**Starter instruction**
`Return: executive answer, evidence table, strongest counterargument, unknowns, and primary-source links. Mark every inference as an inference.`
Acceptance test
**Every material claim has a direct source, at least one counterpoint is represented and unsupported statements are visibly marked.**
**Keep** — Question, report and opened source set
**Boundary** — No consequential medical, legal or financial decision without qualified review
**Failure signal** — Citations point to search results, summaries or sources that do not support the sentence
Implementation example: [OpenAI deep research](https://openai.com/index/introducing-deep-research/) (vendor documentation).
02
Turn a meeting into decisions and tasks
Transcribe locally, extract structured outcomes and keep a person responsible for publication.
30 min
Beginner
Runs locally
**Deliverable:** an approved meeting record with decisions, owners, due dates and open questions.
### Build it
1. 01 **Confirm consent and retention.** Tell participants what is recorded, where it is processed and when the audio will be deleted.
2. 02 **Create a timestamped transcript.** Run transcription locally when the recording is sensitive. Correct participant names and domain terms before summarization.
3. 03 **Extract a fixed schema.** Request decisions, action, owner, due date, supporting timestamp and unresolved questions. Do not infer missing owners.
4. 04 **Approve and publish.** A participant compares every decision and action against the transcript before copying them into the system of record.
**Extraction schema**
`Return decisions and actions as tables. Every row needs a transcript timestamp. Use "unassigned" and "no date stated" when the meeting did not specify them.`
Acceptance test
**Every published action is traceable to a timestamp and the system invents no owner, deadline or decision.**
**Keep** — Approved notes and retention decision; delete raw audio on schedule
**Boundary** — Recording consent, employment rules and sensitive discussions require local policy
**Failure signal** — Polished minutes include commitments nobody actually made
Local transcription implementation: [OpenAI Whisper](https://github.com/openai/whisper) .
03
Evaluate a workflow over ten runs
Measure one of the first two supervised workflows before adding retrieval, tools or autonomy.
60 min
Beginner
Any workflow
**Deliverable:** a run log, failure set and explicit adopt, revise or stop decision.
### Build it
1. 01 **Record the manual baseline.** Complete three examples without AI. Capture elapsed time, quality checks and the corrections normally required.
2. 02 **Write the rubric first.** Score correctness, completeness, saved minutes, correction minutes and critical failures. Define what automatically fails a run.
3. 03 **Run representative work.** Use ten cases across easy, ordinary and difficult examples. Keep the model, instructions and tool permissions fixed.
4. 04 **Make a decision.** Adopt only when net time and quality improve without an unacceptable failure. Otherwise narrow the task, improve controls or stop.
**Starting threshold**
`At least 8 of 10 outputs are usable after review, no critical failure occurs, and total minutes saved exceed setup plus correction time. Adjust this threshold to the actual risk.`
Acceptance test
**Another person can reproduce the result from the saved cases, rubric, configuration and run log.**
**Keep** — Baseline, cases, model and prompt version, scores, corrections and decision
**Boundary** — One severe safety or authority failure resets expansion even when average quality is high
**Failure signal** — The score changes after seeing the output or only successful examples are retained
**Builds on:** use the output from the [research brief](#research-brief) or [meeting-actions guide](#meeting-actions) as your first test fixture. Evaluation references: [NIST AI RMF Playbook](https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook) and [Anthropic agent evals](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) .
04
Extract fields from incoming documents
Build on the evaluation pattern with fixed schemas, provenance and deterministic validation.
60-90 min
Intermediate
Local or cloud
**Deliverable:** one fixed-schema record, page-level provenance, validation results and a review queue for uncertain fields.
### Build it
1. 01 **Freeze the schema.** Name required fields, data types, allowed values and which fields may be absent. Do not ask for an open-ended summary.
2. 02 **Parse with provenance.** Retain filename, page, table position and the source text behind every extracted value.
3. 03 **Validate deterministically.** Check dates, identifiers, line-item arithmetic, currency and totals in code. Route any mismatch or low-confidence field to review.
4. 04 **Test the ugly examples.** Include scans, rotated pages, missing fields, duplicate documents and layouts from different suppliers before live use.
**Extraction contract**
`Return only the supplied schema. Include source page and exact supporting text for every field. Use null when absent. Never repair totals or infer a missing identifier.`
Acceptance test
**Every accepted field is traceable to a page, deterministic checks pass and uncertain records remain drafts.**
**Keep** — Original document, parsed structure, schema, validations and reviewer correction
**Boundary** — No posting to finance, CRM or case systems without a separate approval or validated import step
**Failure signal** — The record looks complete because the model invents absent values or silently fixes inconsistent totals
Parsing implementation: [Docling](https://github.com/docling-project/docling) . Evaluation method: [ten-run guide](#ten-run-evaluation) .
05
Question a private document collection
Turn the earlier parsing and provenance pattern into a private, locally controlled retrieval system.
Half day
Intermediate
Local GPU helpful
**Deliverable:** a searchable collection that cites the source document and page for every answer.
### Build it
1. 01 **Choose a bounded collection.** Start with 20-50 documents you understand. Classify sensitivity and remove files that should not enter the system.
2. 02 **Parse without losing provenance.** Extract text, tables and headings while retaining filename, page number and a stable link to the original.
3. 03 **Index locally.** Create one isolated workspace, use a local embedding model and confirm that telemetry, backups and model endpoints match your privacy requirement.
4. 04 **Test retrieval, including absence.** Ask ten questions with known answers and three whose answers are not present. Inspect the retrieved passages, not only the final prose.
**Answer policy**
`Use only retrieved passages. Cite document and page after each claim. If the collection does not support an answer, say "not found in this collection" and list the closest passages.`
Acceptance test
**Known answers cite the correct pages and absent answers produce an explicit refusal instead of plausible filler.**
**Keep** — Original files, parsed output, retrieval test set and configuration
**Boundary** — "Local" is not a guarantee; audit telemetry, model endpoints, plugins and backups
**Failure signal** — Answers cite a document name but cannot identify the supporting passage
**Builds on:** reuse the provenance rules from [document extraction](#document-extraction) and the cases and rubric from the [ten-run evaluation](#ten-run-evaluation) . Open implementations: [Docling](https://github.com/docling-project/docling) , [AnythingLLM](https://github.com/Mintplex-Labs/anything-llm) and [Obsidian](https://obsidian.md/help/) .
06
Draft customer-support replies
Add approved retrieval and escalation to the measured, draft-only workflow.
Half day
Intermediate
Draft only
**Deliverable:** a response draft, cited policy passage, confidence state and escalation recommendation.
### Build it
1. 01 **Assemble the approved context.** Use current policy, product documentation and 20 resolved examples. Exclude exceptions that should remain human-only.
2. 02 **Define routing before wording.** Create categories, mandatory escalations and deterministic tools for prices, account state or refunds.
3. 03 **Draft from retrieved policy.** Require the response to cite its governing passage internally and to ask for missing information rather than assume it.
4. 04 **Grade representative tickets.** Review correctness, policy fit, tone, data handling and escalation across at least 20 historical cases before live use.
**Draft rule**
`Do not invent policy, price, account state or an exception. Cite the internal source used. If the evidence conflicts or is incomplete, draft a clarification and mark the case for review.`
Acceptance test
**All factual commitments come from approved sources or deterministic tools, and ambiguous cases reach a person.**
**Keep** — Test cases, rubric, source version and reviewer corrections
**Boundary** — Redact unnecessary personal data and keep sending behind human approval
**Failure signal** — A fluent draft promises a refund, price or policy exception without authority
**Builds on:** reuse the cited retrieval and absence tests from [private documents](#private-documents) , then apply the [ten-run evaluation](#ten-run-evaluation) to historical tickets. Vendor reference pattern: [Anthropic support guide](https://platform.claude.com/docs/en/about-claude/use-case-guides/customer-support-chat) . Independent field evidence for a different support-assistant deployment: [NBER study](https://www.nber.org/papers/w31161) .
07
Turn an issue into a tested patch
Apply the same contract, baseline and independent-checking pattern to repository work.
60-90 min
Intermediate
Local or cloud
**Deliverable:** a reviewable diff, passing relevant checks and a concise implementation report.
### Build it
1. 01 **Convert the issue into acceptance criteria.** State the current behavior, desired behavior, affected surface and explicit non-goals.
2. 02 **Establish the baseline.** Use a clean branch, run the existing checks and record failures that already exist before the agent edits anything.
3. 03 **Constrain the agent loop.** Ask it to inspect, plan, edit and test. Require it to stop when evidence is missing or the task expands beyond the contract.
4. 04 **Review the artifact yourself.** Read the diff, rerun the claimed commands and inspect for unrelated edits, new dependencies and weakened tests.
**Starter specification**
`Implement only the stated acceptance criteria. Preserve public behavior outside scope. Run the narrowest relevant tests, then the repository check. Report files changed, commands run, results and residual risks.`
Acceptance test
**The new behavior is covered by a test, relevant checks pass and the diff contains no unexplained changes.**
**Keep** — Issue, spec, diff, command output and review notes
**Boundary** — No production secrets, direct deployment or automatic merge
**Failure signal** — The agent changes tests to accept the bug or reports checks it did not run
Tools and references: first learn the complete [reviewable coding loop](https://isaiuseful.com/thinking-with-ai.html.md#loop) , then compare [OpenCode](https://opencode.ai/docs/) , [OpenSpec](https://github.com/Fission-AI/openspec) and the [SWE‑bench family guide](https://isaiuseful.com/benchmarks.html.md#swe-bench) . If this becomes recurring work, use the [loop engineering guide](#loops) before scheduling it.
08
Compare two agent harnesses on one bounded task
Reuse the tested-patch fixture to measure what the surrounding tools, context and controls change.
60–90 min
Intermediate
Disposable workspace
**Deliverable:** a reproducible harness scorecard with run traces, artifacts and an adopt, revise or reject decision.
### Build it
1. 01 **Choose a task with a mechanical finish.** Use a small repository repair, document extraction or read-only investigation with a frozen input and a deterministic test. Record the clean starting state and expected artifact before either harness sees it.
2. 02 **Freeze everything except the harness.** Use the same model, model settings, task specification, starting files, tool permissions, network rule and time, token and attempt caps. Run each candidate in a fresh worktree, container or disposable folder without production credentials.
3. 03 **Run repeatedly and retain the trace.** Give each harness at least five independent attempts. Save elapsed time, input and output tokens, tool calls, retries, changed files, test results, approvals and the complete transcript; a single lucky pass is not the comparison.
4. 04 **Grade the artifact outside the agent.** Run the same deterministic checks on every result, inspect unrelated changes and record manual correction time. Compare pass rate, repeatability, total cost, wall-clock time and boundary violations—not polish or confidence.
5. 05 **Choose the smallest adequate scaffold.** Adopt only if one candidate improves the named workflow at an acceptable cost and authority level. Otherwise narrow the task, change the test or reject both; do not compensate for weak verification with more retries.
**Shared task contract**
`Complete only the supplied task in the disposable workspace. Do not change the acceptance test, access credentials, contact external services or expand scope. Run the named checks, preserve the trace and stop at the time, token or attempt cap. Report the artifact, evidence, failures and remaining risk.`
Acceptance test
**Another person can reset the fixture, rerun both harnesses under the same limits and reproduce the scorecard from saved traces and independently graded artifacts.**
**Keep** — Fixture, task contract, harness and model versions, settings, permissions, traces, artifacts, grader output, cost and decision
**Boundary** — A worktree separates changes, not processes, networks or credentials; test those controls independently
**Failure signal** — One harness gets more context, attempts or authority, the agent edits its grader or only the best run survives
**Builds on:** reuse the fixture and acceptance checks from the [tested-patch guide](#tested-patch) , then grade repeated runs with the [evaluation method](#ten-run-evaluation) . Start with the [browser harness demo](https://isaiuseful.com/benchmarks.html.md#harness-demo) , choose candidates from [software-agent tools](https://isaiuseful.com/tools.html.md#tools-build-software-with-agents) , then compare your scorecard with the narrow [repeated-run efficiency study](https://isaiuseful.com/tools.html.md#harness-efficiency) . For harder reproducible tasks, inspect the [Terminal‑Bench harness](https://isaiuseful.com/benchmarks.html.md#terminal-bench) . These routes demonstrate evaluation methods; they do not establish a universal harness ranking.
09
Run a bounded recurring automation
Turn one already measured workflow into a logged recurrence with explicit stops and approvals.
Half day
Intermediate
Approval gated
**Deliverable:** one repeatable workflow with least-privilege tools, durable state, logs and a human release gate.
### Build it
1. 01 **Choose a boring loop.** Use a repeated input, a known transformation and a draft output: classify an inbox, prepare a report or update a queue.
2. 02 **Constrain tools and authority.** Give the workflow the smallest read scope possible. Separate drafting from sending, deleting, buying or deploying.
3. 03 **Make state and stops explicit.** Record each input, tool call, output and approval. Define completion, timeout, retry and duplicate-prevention behavior.
4. 04 **Supervise before scheduling.** Run ten representative cases manually, convert recurring failures into rules or tests, then schedule with alerts.
**Operating contract**
`You may read the allowed inputs and prepare a draft. Stop on missing data, tool failure, conflicting instructions or any action outside scope. Never send, delete, purchase or deploy.`
Acceptance test
**The workflow can resume safely, never duplicates side effects and stops cleanly when evidence or authority is missing.**
**Keep** — Workflow contract, permissions, run log, failure set and approval record
**Boundary** — External side effects stay gated until the risk is understood and separately controlled
**Failure signal** — Retries send twice, state disappears between runs or the agent quietly expands scope
**Builds on:** schedule only a workflow that has passed the [ten-run evaluation](#ten-run-evaluation) ; use the [harness comparison](#harness-bake-off) when the runtime itself is still a choice. Design references: [building effective agents](https://www.anthropic.com/engineering/building-effective-agents) and [long-running harnesses](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents) .
10
Run a local, permission-bounded assistant
Combine private retrieval and bounded automation, then control the local runtime safely from a phone.
Half day
Intermediate
Local GPU helpful
**Deliverable:** a locally hosted assistant with a documented data boundary, one useful skill, an action log and a kill switch.
### Build it
1. 01 **Draw the boundary first.** List allowed folders, network endpoints, users and retention. Check telemetry, plugins, backups and fallback providers.
2. 02 **Prove the model on the task.** Test a small local model on ten representative cases before buying hardware or adding tools.
3. 03 **Add one read source and one draft tool.** For example: search a notes folder and prepare a daily brief. Do not start with email sending, purchasing or shell access.
4. 04 **Add pocket control at the gateway.** Put an authenticated browser, companion app or messaging surface in front of the agent. Reach that surface through a private Tailnet or SSH tunnel; keep Ollama, LM Studio, vLLM and retrieval services on loopback or an internal network.
5. 05 **Log, review and stop.** Show whether the model runs on the phone, home host or cloud; record retrieval and tool calls, cap loop length and cost, and keep an obvious way to disable the service and revoke credentials.
**Permission contract**
`You may read only the allowlisted source and prepare a draft. Do not send, delete, rename, purchase, execute or contact external services. Stop after one failed tool call and report it.`
Acceptance test
**From cellular data, the phone reaches only the authenticated control surface; the assistant completes the workflow, makes no unapproved network call and cannot access a deliberately disallowed file.**
**Keep** — Boundary diagram, configuration, model version, ten-run result and tool log
**Boundary** — Local inference and remote transport are separate: include the tunnel, relay or messaging provider in the privacy review
**Failure signal** — A raw backend port is public, or a plugin, fallback model, relay or backup silently sends private context elsewhere
**Builds on:** combine the allowlisted corpus from [private documents](#private-documents) with the stops, logs and approval boundary from [bounded automation](#bounded-automation) . Remote-control references: [OpenClaw gateway access](https://docs.openclaw.ai/gateway/remote) , [Hermes messaging](https://hermes-agent.nousresearch.com/docs/user-guide/messaging/) and the [private operator pattern](https://isaiuseful.com/remote-spark.html.md#operators) . Other local-assistant options include [AnythingLLM](https://github.com/Mintplex-Labs/anything-llm) .
11
Audit and harden a UniFi network with AI
Move from screenshots to a GET-only API audit, then gate every firewall, zone and VLAN change.
Half day
Intermediate
Privileged infrastructure
**Deliverable:** a redacted network inventory, zone and policy matrix, prioritized findings, an ordered change plan and pre/post-change test evidence.
### Build it in three levels
1. 01 **Prepare the boundary and recovery path.** Use a local coding agent that can run a small API client. Confirm you can reach the UniFi console without the path you may change, take a current backup and record the Network version. Generate a dedicated API key in Site Manager or the console's Integrations area; prefer a one-month expiry, or set a dated reminder to revoke it.
2. 02 **Level 1 · Explain screenshots.** Start without API access. Redact public IPs, MAC addresses, SSIDs, client names and other identifiers from roaming logs, connectivity failures or RF charts, then ask for a plain-English diagnosis, competing explanations and the next measurement that would distinguish them.
3. 03 **Level 2 · Build a GET-only audit.** Keep the key in an ignored local `.env` file—never in chat, source control, command output or a generated dashboard. Put a mechanical wrapper in front of the agent that permits only `GET` , then inventory sites, devices, clients, networks, Wi-Fi broadcasts, firewall zones and ordered policies. Save a redacted baseline and build dashboards only from that bounded read path.
4. 04 **Turn findings into a testable design.** Have the agent map users, servers, IoT, cameras, guests, management and VPN access into named trust zones. For every proposed VLAN or policy, require source, destination, protocol or service, rule order, business reason, affected dependencies, expected result and rollback. Treat undocumented legacy-firewall objects, NAT, VPN and implicit rules as unresolved—not invitations to guess.
5. 05 **Level 3 · Approve one mutation at a time.** Review the exact API method, URL and redacted body before it runs. Prefer a new disabled policy when supported, keep management access untouched and never batch a firewall migration. After each approved write, re-read live state and test both traffic directions plus DNS, DHCP, admin, VPN and any device-discovery flows the change may affect.
6. 06 **Close the access.** Compare the final state with the plan, preserve the change log without secrets, verify rollback instructions and revoke the project key when the audit or migration ends. Renew a dashboard key intentionally rather than leaving forgotten access active.
**Staged operating contract**
`Start in screenshot or read-only mode. Load UNIFI_API_KEY only from the ignored local .env file; never print, paste, log or commit it. Permit GET requests only and save a redacted baseline. Return a zone/VLAN/firewall audit, evidence, an ordered proposal, dependency tests and rollback steps. Do not issue POST, PUT, PATCH or DELETE until I approve one exact request. After each approved change, re-read state, run the named tests and stop on any unexpected result.`
Acceptance test
**The audit is reproducible without exposing the key, every live change has one recorded approval and rollback, and the administrator can still reach the console after the network tests pass.**
**Needs** — A UniFi gateway or firewall, its Network API, network devices to inspect and a local tool-capable AI environment; a legacy firewall export is optional
**Keep** — Network and API versions, redacted inventory, policy order, proposals, approvals, responses, tests, rollback evidence and key revoke date—never the key
**Boundary** — AI can expose stale rules and prepare precise changes; it does not replace networking knowledge, an independent review or an out-of-band recovery path
**Failure signal** — A secret appears in chat or Git, the audit tool accepts write verbs, a rule lacks dependency tests or several live policies change before verification
**Builds on:** use the permission and kill-switch pattern from the [local assistant](#local-assistant) , the repeated checks from the [evaluation guide](#ten-run-evaluation) and the approval boundary from [bounded automation](#bounded-automation) . Official references: [UniFi API overview](https://help.ui.com/hc/en-us/articles/30076656117655-Getting-Started-with-the-Official-UniFi-API) , [current Network API](https://developer.ui.com/network) , [zone-based firewalling](https://help.ui.com/hc/en-us/articles/115003173168-Zone-Based-Firewalls-in-UniFi) and [virtual networks and VLAN assignment](https://help.ui.com/hc/en-us/articles/9761080275607-Creating-Virtual-Networks-VLANs) .
12
Build a linked second brain with a reviewable AI loop
Combine durable notes, derived retrieval, fact memory and the earlier review-only loop.
Half day
Intermediate
Local-first
**Deliverable:** a portable Markdown vault, a disposable search index, an optional correctable fact graph and one logged loop that prepares a review queue.
### Build it
1. 01 **Make the vault the source of truth.** Create `Inbox` , `Sources` , `Notes` , `Projects` and `AI Review` folders. Each durable note needs a clear title, source link, capture date and status. Use ordinary Markdown and links so the knowledge survives any one app or model.
2. 02 **Build a derived retrieval layer.** Parse only allowlisted notes, split Markdown by headings and meaning with Chonkie, preserve each file path and heading, then embed the chunks into a replaceable vector store. Rebuild the index from the vault; never make the index the only copy. [Follow the RAG build sequence](https://isaiuseful.com/rag.html.md#build) .
3. 03 **Separate documents from facts.** Use retrieval for quotations, arguments and changing source material. If you need stable relationships such as people, projects, systems and ownership, test FaultLine as a separate, correctable fact graph. Require a source note or explicit human confirmation before a fact becomes authoritative.
4. 04 **Add one loop-engineering job.** On a schedule, read new inbox notes, suggest links to existing notes, identify duplicates and draft one synthesis note in `AI Review` . Persist the last processed file and run result outside the conversation so the next run can resume without guessing.
5. 05 **Verify before promotion.** A separate check confirms every proposed link resolves, every quoted claim points to a source and no canonical note was changed. A person accepts, edits or rejects each draft before moving it into `Notes` .
**Loop contract**
`Read only allowlisted vault folders. Write only to AI Review. For each suggestion, cite the source note and heading. Do not delete, rename, retag or rewrite canonical notes. Stop on a broken link, missing provenance or conflicting fact and add it to the review queue.`
**What the graph means**
Obsidian's graph view visualizes links between notes. It can look neural, but it is not a neural network and dense connectivity is not proof of useful knowledge. Judge the system by whether you can recover a source, answer a real question and keep incorrect facts correctable.
Acceptance test
**Five known questions retrieve the right source passages, one absent answer is refused, every suggested link resolves and the scheduled run changes only the review folder.**
**Keep** — Markdown vault, attachments, source metadata, index recipe, fact corrections, loop state and review decisions
**Boundary** — Community plugins execute code; audit them and any sync, embedding or model endpoint before allowing private notes
**Failure signal** — The generated summary replaces the source, the graph rewards link spam or an unverified memory silently overrides a cited note
**Builds on:** extend the [private-document collection](#private-documents) with the review-only recurrence from [bounded automation](#bounded-automation) . Building blocks: [Obsidian](https://obsidian.md/help/) , [Chonkie](https://github.com/feyninc/chonkie) and [FaultLine](https://github.com/tkalevra/FaultLine) . Loop design references: the [Loop Engineering repository](https://github.com/cobusgreyling/loop-engineering) and [Addy Osmani's overview](https://addyosmani.com/blog/loop-engineering/) .
13
Confirm tomorrow's appointments and refill cancellations
Add voice, calendar state and reversible side effects to the bounded-automation pattern.
Pilot project
Intermediate
Local or cloud
**Deliverable:** a supervised appointment-confirmation loop with a locked waitlist offer, an auditable outcome for every call and a reconciliation report against the calendar.
### Build it
1. 01 **Snapshot tomorrow's eligible appointments.** At 17:00, let Logic Apps, n8n or another scheduler read the shared calendar and create one work item per appointment. Keep a stable appointment ID, start time, version and status; exclude entries without contact permission or enough data to match the attendee safely.
2. 02 **Make a deliberately small call.** Have a worker place the call through Azure Communication Services, Twilio or your own PBX and SIP operator. State who is calling and why, disclose automation where required, and offer fixed choices: confirm, cannot attend, repeat or speak to a person. Prefer keypad confirmation; map speech only to those states.
3. 03 **Confirm before releasing the slot.** Read the date and time back and require a second explicit answer before changing the booking. Silence, voicemail, low-confidence speech, identity uncertainty or a request outside the script becomes unresolved—never a cancellation.
4. 04 **Offer one locked slot at a time.** Query PostgreSQL for the next eligible, opted-in person using your existing priority rules. Atomically create an expiring offer for the open slot, call that person and continue only after decline or expiry. On acceptance, commit the booking and verify the calendar write before ending the call.
5. 05 **Reconcile, then continue.** Use idempotency keys for appointments, calls and offers so retries cannot cancel or book twice. After each outcome—and once at the end—compare the queue, database and calendar; alert a person about conflicts, failed writes and appointments that remain unconfirmed.
**Conversation contract**
`You may classify the caller's answer only as CONFIRM, CANNOT_ATTEND, REPEAT, HUMAN or UNCLEAR. Never invent, move or promise a time. A booking changes only after explicit confirmation and a successful scheduling-system response.`
True OSS route
### Keep the carrier contract. Own the application stack.
The phone network is still a paid service, but it does not require a communications cloud. Buy a SIP trunk and phone number from a local operator; keep scheduling, call control, speech and workflow state on infrastructure you operate.
> Visual: Open-source appointment calling stack
**Visual reading order:**
1. **01 · Calendar** **CalDAV** Nextcloud or Radicale; use a direct Microsoft Graph adapter only when the existing calendar is Microsoft 365.
2. **02 · Durable workflow** **Temporal + .NET worker** One workflow per appointment; timers, retries and signals survive restarts. Node-RED is the Apache-licensed visual alternative; n8n remains a self-hostable fair-code option.
3. **03 · Source of truth** **PostgreSQL** Appointments, consent, waitlist rank, call attempts and expiring offers live in relational transactions—not model memory.
4. **04 · Calls** **Asterisk or FreeSWITCH** Connect the PBX to the operator's SIP trunk. Use Asterisk ARI or FreeSWITCH ESL for originate, answer, DTMF, playback, hangup and call events.
5. **05 · Speech to text** **Speaches + faster-whisper** Stream narrow call audio to a local OpenAI-compatible STT endpoint. whisper.cpp is a lean CPU/edge alternative; always retain a DTMF path.
6. **06 · Text to speech** **Speaches or Kokoro-FastAPI** Generate local prompts through an OpenAI-compatible speech endpoint. openedai-speech documents the older Piper/XTTS pattern but is archived and should not be the new default.
7. **07 · Media loop** **ARI external media or Pipecat** Bridge RTP/WebSocket audio, voice activity, interruption and transcoding. A local LLM may classify free speech, but only into the five allowed states.
8. **08 · Operations** **OpenTelemetry + Grafana** Measure answer rate, STT latency, intent confidence, retries, slot locks and reconciliation failures without storing call audio by default.
### Wire the OSS path
1. A **Prove the telephone boundary first.** Get the SIP trunk, outbound caller ID and allowed calling regions in writing. From Asterisk or FreeSWITCH, place test calls, receive DTMF, play a WAV prompt and confirm hangup events before adding speech AI.
2. B **Run one durable state machine per appointment.** A Temporal schedule starts the nightly scan; a .NET worker reads CalDAV, writes the snapshot to PostgreSQL and starts child workflows with IDs such as `appointment:{calendar-id}:{version}` . Signals carry call outcomes back; activities perform all network and database I/O.
3. C **Keep media separate from booking authority.** Asterisk ARI originates the PJSIP channel and attaches an external-media channel. The media service converts the negotiated codec to the format expected by Speaches, applies VAD/barge-in and sends synthesized PCM back. It returns an intent event—not a calendar mutation.
4. D **Make the final choice deterministic.** For cancellation or offer acceptance, play a generated read-back and require DTMF or a second high-confidence answer. The .NET worker validates the current appointment version and performs one PostgreSQL transaction before writing the calendar.
5. E **Test crash and ambiguity paths.** Kill the worker mid-call, replay a webhook/event, drop STT, let an offer expire and change the calendar concurrently. The workflow must resume without a second call, release abandoned locks and route uncertainty to the human queue.
- [Temporal .NET SDK →](https://github.com/temporalio/sdk-dotnet)
- [Asterisk external media →](https://docs.asterisk.org/Development/Reference-Information/Asterisk-Framework-and-API-Examples/External-Media-and-ARI/)
- [Speaches →](https://github.com/speaches-ai/speaches)
- [Pipecat →](https://github.com/pipecat-ai/pipecat)
Acceptance test
**Every next-day appointment ends confirmed, explicitly released or visibly unresolved; each open slot has at most one live offer; and the final calendar contains no duplicate booking.**
**Keep** — Consent basis, appointment version, call and offer state, calendar response, retries and final reconciliation
**Boundary** — Apply local calling-hour, identification, recording, privacy and opt-out rules; disclose only the minimum appointment detail
**Failure signal** — Speech recognition releases a slot, two people receive a live offer, or the caller hears success before the calendar confirms it
**Builds on:** promote the state, idempotency and approval rules from [bounded automation](#bounded-automation) before adding outbound calls or calendar writes. Azure building blocks: [Logic Apps + Outlook calendar](https://learn.microsoft.com/en-us/azure/connectors/connectors-create-api-office365-outlook) and [ACS outbound call + choice recognition](https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/call-automation/quickstart-make-an-outbound-call) . Alternative voice layer: [Twilio outbound calls](https://www.twilio.com/docs/voice/tutorials/how-to-make-outbound-phone-calls) and [speech/DTMF gathering](https://www.twilio.com/docs/voice/twiml/gather) .
OSS building blocks: [Asterisk](https://github.com/asterisk/asterisk) or [FreeSWITCH](https://github.com/signalwire/freeswitch) , [Speaches](https://github.com/speaches-ai/speaches) , [faster-whisper](https://github.com/SYSTRAN/faster-whisper) , [Kokoro-FastAPI](https://github.com/remsky/Kokoro-FastAPI) and archived reference [openedai-speech](https://github.com/matatonic/openedai-speech) .
Related operational evidence—not a test of this voice design: a [2025 Mayo Clinic study](https://journals.sagepub.com/doi/10.1177/11786329251326461) reported 56,636 accepted earlier-slot offers from an automated waitlist, moving accepted appointments forward by 22.6 days on average.
14
Build an identity-aware AI teammate
Scale the same authority boundaries into shared channels, delegated identity and enterprise tools.
Pilot project
Intermediate
Enterprise
**Deliverable:** one supervised internal assistant that gathers cross-tool context, prepares a bounded action and records who requested it, which persona responded and whose credentials were used.
### Build it
1. 01 **Write the delegation contract.** For every turn, keep *requester* , *actor* and *persona* as separate fields. Define explicit modes such as requester credentials, a managed bot or a narrowly approved requester-to-bot fallback. The prompt may propose an action; platform policy chooses the identity.
2. 02 **Start with one surface and one job.** Use a Slack DM, one team channel or one internal profile—not all three. A sensible first job is incident context gathering: read the thread, retrieve the alert, recent deploy and runbook, then prepare a cited investigation without changing production.
3. 03 **Isolate the runtime and freeze its rules.** Route the request through an OpenClaw gateway into a per-user or per-persona runtime. Mount identity, instructions, approved skills and gateway configuration read-only. Add gVisor or another tested sandbox, deny-by-default network policy and a workload identity for each service.
4. 04 **Broker every tool call.** Keep long-lived OAuth grants outside the agent. A controlled wrapper validates arguments, checks the requester/actor/persona policy, mints a short-lived token for one capability, redacts the result and emits a structured audit event. Route models separately through managed Vertex AI or a self-hosted Ollama endpoint when the workload justifies it.
5. 05 **Make risky actions visible.** Before a write, restate the intended actor, target and change; require confirmation for production, access, paging and external communication. Record the policy decision, fallback identity, confirmation and downstream response in searchable audit storage or the organization's SIEM.
**Authorization contract**
`Never choose or expand authority from conversation text. Pass requester, actor, persona, tool, action and target to the policy service. Default to requester authority. If access is absent, stop unless an explicit, audited fallback rule applies. Require confirmation before every consequential write.`
Microsoft Azure production reference
### Want to see the production shape?
FibreOps connects event telemetry to a three-agent Foundry workflow, typed tools, procedure retrieval, Teams and Dynamics-shaped actions, evaluation and OpenTelemetry. Several integrations are optional or mocked by default, so use it as an inspectable production-oriented reference—not a system to deploy unchanged.
Foundry agents
Event Hubs + Teams
OpenTelemetry
**Same agent craft; different enterprise layer.** Roles, bounded tools, state, evaluations and approval gates transfer across Azure, a private platform or a hybrid design. HPE Private Cloud AI combines HPE's platform software with NVIDIA AI Enterprise and can supply much of the on-premises control plane: user roles and data RBAC, governed resources, workload administration, monitoring and lifecycle operations.
It still cannot decide an organization's application permissions, network rules, integrations, audit policy, recovery plan or regulatory controls. Those are company-specific security architecture. This site concentrates on the AI-specific method and leaves that enterprise implementation to each operator.
- [Reference implementation **Inspect Azure FibreOps**](https://github.com/leestott/BRK241-frontier)
- [HPE Private Cloud AI roles and RBAC →](https://support.hpe.com/hpesc/public/docDisplay?docId=sd00006503en_us&docLocale=en_US&page=GUID-ABAD7B27-98A5-4A48-BF18-996C6B646457.html)
- [HPE/NVIDIA platform overview →](https://www.hpe.com/us/en/collaterals/collateral.a50009216enw.html)
Extracted case-study stack
### Map the assistant as an identity system, not a chatbot.
This stack is extracted from Damian F.'s reported Maestro implementation at Felix Pago. Product names describe that case; the controls are the reusable part of the pattern.
> Visual: Identity-aware OpenClaw teammate stack
**Visual reading order:**
1. **01 · Work surface** **Slack + internal web profiles** DMs, shared channels and published employee context are separate interaction modes with different actor policy.
2. **02 · Agent gateway** **OpenClaw** Routes channels, sessions, tools and model backends into isolated user or persona runtimes.
3. **03 · Runtime fleet** **GKE + Kubernetes + gVisor** Per-agent pods, lifecycle management and a stronger sandbox boundary around model-driven code and tools.
4. **04 · Service identity** **Istio + mTLS + SPIFFE** Workloads authenticate each other; network policy limits which runtimes can reach gateways, vaults and token services.
5. **05 · Model routing** **Vertex AI + Ollama** Managed models serve higher-stakes work while self-hosted GPU models cover suitable routine or high-volume tasks.
6. **06 · Delegated access** **OAuth vault + token minting** Durable grants stay outside the runtime; wrappers receive scoped, short-lived credentials for one invocation.
7. **07 · Work tools** **GitHub + Workspace + ClickUp + Notion** Constrained wrappers gather code, documents, tickets and knowledge under the selected actor's existing permissions.
8. **08 · Incident evidence** **PagerDuty + New Relic + SIEM** Alerts and telemetry become cited investigation context; session and tool events feed operational and security review.
- [OpenClaw →](https://docs.openclaw.ai/)
- [Slack platform →](https://docs.slack.dev/)
- [GKE →](https://cloud.google.com/kubernetes-engine/docs)
- [gVisor →](https://gvisor.dev/docs/)
- [Istio →](https://istio.io/latest/docs/)
- [SPIFFE →](https://spiffe.io/docs/latest/)
- [Vertex AI →](https://cloud.google.com/vertex-ai/generative-ai/docs/overview)
- [Ollama →](https://docs.ollama.com/)
Acceptance test
**A profile or shared persona can answer from published context, but an external lookup uses the requester's access; a denied request cannot borrow the profile owner's identity; and every write records requester, actor, persona, tool, target and confirmation.**
**Keep** — Identity tuple, policy decision, token scope and lifetime, tool request and response, confirmation, model route and audit event
**Boundary** — No long-lived credentials in the runtime; no prompt-selected identity; no shared persona or fallback bot without an owner and reviewed policy
**Failure signal** — A profile assistant reads as the profile owner, a shared channel hides the human requester or a tool receives a broad reusable token
**Builds on:** carry forward the least-privilege runtime from the [local assistant](#local-assistant) and the explicit side-effect gates from [bounded automation](#bounded-automation) . Case source: Damian F., [Building an Identity-Aware AI Teammate for Real Work Using OpenClaw](https://www.linkedin.com/pulse/building-identity-aware-ai-teammate-real-work-using-openclaw-finol-mpbrc/) (published June 26, 2026). The architecture and scale statements above are the author's report, not independently audited claims.
Loop engineering
## Design the system that prompts the agent.
A good prompt can finish one task. A loop repeatedly discovers work, carries state forward, verifies the result and knows when to stop or ask a person.
Stay one-shot
### Keep a person in the prompt.
Use a supervised agent session when the request is rare, the goal is ambiguous, the acceptance test is subjective or the action could affect production, money, identity or customer data.
Engineer a loop
### Automate only a boring recurrence.
Consider a loop when the same trigger recurs, inputs and permissions can be bounded, completion is independently testable and a failed attempt can stop without causing harm.
> Visual: Anatomy of a safe agent loop
**Visual reading order:**
1. **01** **Trigger** Run on a useful event or cadence. Exit cheaply when there is no work.
2. **02** **Skill** State one job, non-goals, watched scope and a structured output.
3. **03** **State** Read and update durable memory outside the conversation; prune stale items.
4. **04** **Isolation** Give each change its own branch or worktree and never expose secrets.
5. **05** **Maker + checker** Use separate implementation and verification contexts. The maker cannot approve itself.
6. **06** **Gate + log** Cap attempts and spend, record outcomes, then act only inside an allowlist or escalate.
Pattern picker
### Match the loop to the event, evidence and authority.
Choose the smallest control flow that fits the recurrence. “Shape” describes how work moves through the system—not how many agents to hire—and the final column is a starting ceiling, not a target for later autonomy.
| Situation | Trigger | Shape | Independent verification | Starting authority ceiling |
| --- | --- | --- | --- | --- |
| Daily report | Schedule | Chain Read → compare → report | Required schema, source links and a deterministic change diff | Report only |
| CI failure | Failed check | Router → merge-verify Classify → isolate → test | Named tests plus a fresh-context review of the complete diff | Prepare an isolated patch; a person merges |
| Issue implementation | Manual kickoff | Maker → checker Plan → edit → verify | Acceptance tests, denylisted-path check and unexplained-diff review | Propose a reviewable change; no deploy |
| Inbox triage | New item | Router Classify → queue → escalate | Sampled human review, false-alarm rate and missed-item audit | Draft or label only; do not send |
**Step 1 · Contract**
### Make “done” mechanical.
Choose one repository, branch or ticket queue. Write the goal, explicit non-goals, required tests, denylisted paths and the conditions that require human review.
**Step 2 · Memory**
### Persist facts, not chat.
Keep a small state file or board with item IDs, status, timestamps, attempt count and the last verified result. Read it first and clean it after every run.
**Step 3 · Control**
### Separate making from checking.
Let one context prepare the patch and a fresh context inspect the diff and rerun tests. Stop after a fixed number of failed attempts; do not retry a flaky test into submission.
**Step 4 · Operations**
### Budget the cadence.
Log runs, cost, actions and escalations. Check permissions mechanically, keep a kill switch and notify a person only when a decision or intervention is required.
**L0**
**Draft**
Purpose and boundaries documented.
**L1**
**Report**
Triage and update state; take no action.
**L2**
**Assist**
Prepare small, isolated changes for independent verification.
**L3**
**Unattended**
Run only after every safety, budget and observability gate is proven.
- [Video: 6 days autonomous coding](https://www.youtube.com/watch?v=VG2OWqBk0Gk)
Inspiration · Qwen vendor demonstration
### See what a sustained coding loop can aim for.
Qwen presents a six-day autonomous coding run as an ambitious view of what loop engineering can achieve. Use it to look for ideas about task selection, state, verification and recovery—but treat the video as inspiration, not evidence that your own unattended loop is ready. Reproduce the result on isolated, reversible work and measure it against the gates above.
A safer first loop
### Start with a daily, report-only triage.
Summarize actionable issues or failing checks into a state file. Run it supervised at least ten times. Measure missed items, false alarms, stale state, time saved and cost before allowing even a small patch.
**Starter loop contract**
`Read the allowlisted queue and prior state. Report only new, changed or blocked items in the required schema. Do not edit code, comment, merge, deploy or contact anyone. If evidence is missing, permissions fail or an item has reached the attempt cap, record the reason and escalate. Update the run log, then stop.`
**Stop the loop when**
the same item fails three times
state no longer matches the live system
the checker shares the maker's context
cost exceeds its daily cap
a change touches a denied path
Primary practitioner reference: [Loop Engineering repository](https://github.com/cobusgreyling/loop-engineering) . Go deeper with its [five-minute quickstart](https://github.com/cobusgreyling/loop-engineering/blob/main/docs/QUICKSTART.md) , [pattern picker](https://github.com/cobusgreyling/loop-engineering/blob/main/docs/pattern-picker.md) , [readiness checklist](https://github.com/cobusgreyling/loop-engineering/blob/main/docs/loop-design-checklist.md) and [safety guide](https://github.com/cobusgreyling/loop-engineering/blob/main/docs/safety.md) . Before scheduling anything, use the [hands-on harness comparison](#harness-bake-off) to test the surrounding scaffold on your own task. These are practitioner patterns, not evidence that unattended agents are reliable.
Implementation paths
## Pick an operating model before a product.
The right path follows data sensitivity, workflow stability, internal skills and the cost of operating another system.
| Path | Best when | Data boundary | Operating load | First proof |
| --- | --- | --- | --- | --- |
| Hosted assistant Fastest start | One person or team needs a general model now and approved data can leave the organization. | Vendor account, retention and training terms must match policy. | Low | Run ten redacted cases in an existing product; export outputs and corrections. |
| Local desktop Private baseline | One user has repeated private work that a smaller local model handles well. | Can stay on-device only after endpoints, telemetry, plugins and fallbacks are checked. | Medium | Use existing hardware, one runtime and one interface before buying a workstation. |
| Rented GPU job Burst compute | Fine-tuning, batch inference or evaluation needs more memory for hours or days—not a server purchase. | Region, disks, snapshots, logs, subprocessors, deletion and weight export must all meet policy. | Medium | Run one LoRA job on a redacted dataset, export the adapter and destroy the instance. |
| Self-hosted workspace Shared control | A team needs shared retrieval, identity, model routing and centralized logs. | Organization-controlled network, storage, auth, backups and model endpoints. | High | One collection, one group, read-only access and a named service owner. |
| Agent inside a work tool Artifact first | The deliverable lives in a repository, IDE, ticket system or other reviewable surface. | Scoped repository, account and tool permissions; secrets excluded. | Medium | Draft or patch only; require a diff, tests, citations or a preview. |
| Custom workflow or API Stable volume | Inputs, outputs and business rules are stable enough to justify engineering and evaluation. | Explicit per step; minimize context sent to each model and tool. | High | One queue, fixed schema, deterministic validations and human release. |
> Visual: Reference AI workflow architecture
**Visual reading order:**
1. **01** **Intake** Authenticate, classify and minimize the input.
2. **02** **Context** Retrieve allowlisted sources with provenance.
3. **03** **Route** Choose local, hosted or no model by policy.
4. **04** **Tools** Use deterministic code for facts and side effects.
5. **05** **Approve** Gate consequential actions and uncertainty.
6. **06** **Evaluate** Log outcome, correction, cost and failure.
Hardware decision
## Buy only after the workflow passes.
Model size alone does not determine usefulness. Measure quality, latency, concurrency, context and sustained throughput on your own cases.
Start here
### Existing computer
Use hosted models or test a small local model. Best for proving demand without a dedicated purchase.
One power user
### Consumer GPU or high-memory desktop
Good for private drafting, coding, extraction and transcription when a quantized model passes the test set.
Dedicated service
### AI workstation or server
Consider for larger models, long context or multiple users only after utilization and support ownership are clear.
Short training runs
### Rented European GPU
Rent the memory topology the job needs, export checkpoints promptly and verify the region and deletion path—not only the provider's headquarters.
Irregular frontier work
### Hosted model API
Fits bursty demand and advanced models without operating GPUs. Add budgets, data rules, caching and visible escalation.
Local and rented fine-tuning
## Tune behavior—not a changing knowledge base.
Fine-tuning is a measured training project, not a stronger prompt. Start only after a baseline shows a repeated, teachable failure.
**Prompt first**
If a clear instruction plus a few examples works, keep the base model. It is cheaper to change and easier to audit.
**Retrieve facts**
Use [RAG](https://isaiuseful.com/rag.html.md) for private, cited or frequently changing information. Weight updates are a poor document database.
**LoRA next**
Use an adapter for stable format, tone or task behavior that examples repeatedly improve. Keep the base and adapter versions separate.
**Full SFT last**
Consider full supervised fine-tuning only when an adapter is insufficient and the evaluation gain justifies much more compute and operational risk.
A defensible run
### Dataset → baseline → adapter → holdout → export
Remove secrets and unlicensed material; split train, validation and untouched test cases; record the base model, chat template, code, seed and hyperparameters; then compare the adapter against the unchanged baseline. Test general capability retention as well as the target task.
1. 01 **Write the target.** Name the behavior and a numeric or rubric-based acceptance threshold.
2. 02 **Inspect every source.** Record provenance, consent, license, PII treatment and deduplication.
3. 03 **Start small.** Run LoRA or QLoRA on a small model and a sample before scheduling expensive compute.
4. 04 **Reject regressions.** Use an untouched holdout and human review; an LLM judge is supplementary evidence.
5. 05 **Export before teardown.** Save adapter, tokenizer, config, metrics and a reproducible run manifest.
Cheap iteration
### Existing 24 GB-class GPU
Good for data-pipeline tests and parameter-efficient tuning of smaller models. Memory depends on model, sequence length, batch size, optimizer and quantization—do not size a job from parameter count alone.
Integrated lab
### DGX Spark
NVIDIA publishes Spark recipes for full SFT of a 3B model, LoRA for 8B and 70B models, and 70B QLoRA. Treat those as reproducible starting points, not throughput promises.
- [Use the Spark plan →](https://isaiuseful.com/remote-spark.html.md#spark-training)
Hours to days
### European GPU rental
Choose the exact GPU count, interconnect and region the run needs. Scaleway publishes H100/H100-SXM options and OVHcloud publishes one-to-four-H100 configurations.
- [Scaleway →](https://www.scaleway.com/en/choose-the-right-gpu/)
- [OVHcloud →](https://www.ovhcloud.com/en-gb/public-cloud/gpu/h100/)
Application route
### EuroHPC AI Factories
Eligible European startups and SMEs can apply for industrial access, including playground, fast-lane and larger allocations. This is allocation-based infrastructure—not an instant self-service rental.
- [Official access modes →](https://www.eurohpc-ju.europa.eu/ai-factories/ai-factories-access-modes_en)
European options
## European does not automatically mean sovereign.
Separate the model maker, legal entity, processing region, control plane, support access, subprocessors and key ownership before making a residency claim.
French model company
### Mistral Vibe
Mistral's current user product spans web, mobile, terminal and editor surfaces with chat, work and code modes. It is the current name for the product previously presented as Le Chat.
- [Platform overview →](https://docs.mistral.ai/getting-started/platform-overview)
API + operations
### Mistral Studio and Admin
Studio is the developer console and API surface for models, agents, evaluations and usage; Admin covers organizations, billing, SSO and access policy. Hosted use still requires a data-processing review.
- [Product documentation →](https://docs.mistral.ai/getting-started/platform-overview)
Open-weight route
### Mistral models on your hardware
Mistral documents local deployment through vLLM, TensorRT-LLM, TGI and other runtimes, from a desktop GPU to multi-node servers. Most open models use Apache 2.0, but some use modified terms—check the exact model card before training or redistribution.
- [Deployment guide →](https://docs.mistral.ai/models/deployment)
- [Licensing →](https://help.mistral.ai/en/articles/347393-under-which-license-are-mistral-s-open-models-available)
Public infrastructure
### EuroHPC AI Factories
A European compute and support route for research, startups, SMEs and industry. Access modes differ in eligibility, review and GPU-hour scale, so plan lead time and portability.
- [European Commission overview →](https://digital-strategy.ec.europa.eu/en/policies/ai-factories)
Commercial compute
### Telia, Scaleway and OVHcloud
These cover sales-led sovereign AI infrastructure and self-service European GPU instances. Compare actual region, GPU topology, identity, storage, network egress, snapshots and deletion—not the flag on the homepage.
- [Telia Helsinki →](https://www.telia.fi/en/telia-yrityksena/medialle/artikkeli/gcore-selects-telia-for-ai-gpu-cloud-newsroom)
- [Scaleway →](https://www.scaleway.com/en/choose-the-right-gpu/)
- [OVHcloud →](https://www.ovhcloud.com/en-gb/public-cloud/gpu/h100/)
Procurement test
### Ask seven concrete questions
Where are compute and backups? Who can administer them? Which subprocessors see data? Who holds keys? What is logged? How are disks and snapshots deleted? Can checkpoints and adapters leave without conversion or egress lock-in?
- [Apply it to a training run →](#finetuning)
Authority ladder
## Trust grows one permission at a time.
**01**
**Summarize**
Read supplied material
**02**
**Recommend**
Propose an action
**03**
**Prepare**
Create a draft or patch
**04**
**Act with approval**
Wait at the final gate
**05**
**Act narrowly**
Only after measured reliability
The smallest credible deployment
One workflow. One owner. One test set. One explicit approval boundary.
- [Choose a recipe](#chooser)
- [Check the economics](https://isaiuseful.com/index.html.md#roi)
- [Scale what works](https://isaiuseful.com/adoption.html.md#journey)