We are not building an employee in a box. We are building one local helper that reads approved fictional information, proposes a draft, and stops where a responsible person should decide.
No API key requiredFictional data onlyHuman approval stays visible
The teaching case is Harbor & Pine Home Services, an invented business with three services, one short policy file, and five sample inquiries. The helper has no email account, no CRM connection, no payment tool, and no permission to book work. That limitation is the point: a small boundary is easier to understand and test.
You can follow this workshop in two ways. Watch the Build explains what each part does and what evidence to look for. Build Along adds the exact local steps. Both paths lead to the same judgment: can you explain what entered, what the model proposed, what a person approved, what changed, and how to reverse it?
Watch the BuildRead the expected inputs and outputs before looking at any code.
Build AlongDownload the starter, keep the fictional files unchanged at first, and run each checkpoint in order.
What this helper will never doIt never sends a message, makes a booking, changes a service, promises an outcome, handles a key or alarm code, or reaches a live business system.
A useful agent is not just a prompt and an answer. It is a small loop with a business boundary around every step.
ReceiveOpen one fictional inquiry chosen by the participant.
ReadLoad only the approved catalogue and policy files.
ProposeAsk Codex for one structured draft or a safe stop.
DecideA person sees the complete proposal before a local write.
RecordSave evidence of the approved change and keep an undo path.
The model participates in the middle of the loop. It does not own the file boundary, the approval question, the activity record, or the undo action. Those belong to the small local program. This separation matters because a fluent answer is not proof that the surrounding process is safe.
The model may suggest. The harness controls what can happen. The owner decides what counts as useful and acceptable.
Say the job in one sentenceWhen one fictional inquiry arrives, prepare either a sourced response draft or a clear request for human judgment. Never send it. Save a local draft only after a person approves the preview.
Use an official supported Node.js LTS release. The pilot targets Node.js 24 LTS and also accepts Node.js 22 LTS. The starter uses npx to fetch the current official Codex CLI, then runs it locally. Choose Sign in with ChatGPT for subscription access. An API key uses a separate usage-based billing path and is not part of this workshop.
Protect the sign-inNever paste an API key or the contents of a Codex authentication file into the starter, a prompt, a screenshot, or a support message. If sign-in fails, stop and fix sign-in.
Checkpoint 1 · setup
npm run check
The setup checker looks for Node.js, the current Codex CLI, and an active Codex sign-in. The first run may take a little longer while the CLI is downloaded and cached. It does not read or print credentials. A green setup check means only that the workbench can begin; it does not authorize access to real business data.
Inside this workshop
Fictional catalogue and policies
Fictional inquiries
Local draft files
Local activity history
Outside the boundary
Email and contacts
CRM and calendars
Payments and bookings
Real customer information
Build Along: unzip the starter into its own folder, open a terminal there, and run the setup checkpoint. If it fails, use the included setup checklist rather than guessing.
Before asking the model for anything, read the source files yourself. The catalogue lists three fictional services and starting prices. The policy defines the service area, hours, approval conditions, and requests that must stop for a person.
This is not busywork. If you cannot point to the source for a proposed sentence, you cannot distinguish a useful draft from an invented one. The helper therefore reports the names of the source files alongside every proposal.
Find three boundariesWhat is the service area? Which prices may be quoted? Which requests must stop for a person? If the answer is not visible in the files, do not expect the model to supply it safely.
Watch the Build: notice that the source is small enough to read in one sitting. A larger knowledge base may be useful later, but size is not the same as quality or permission.
The starter's first useful capability is deliberately plain: open the selected inquiry, the service catalogue, and the policy file. The file names must match one of the known fictional cases. A request such as ../../private-file is rejected before any file is opened.
Read-only does not mean risk-free. A read tool can still expose information that should not be in scope. Here, safety comes from both the data being fictional and the program resolving paths only inside its workshop folders.
Automatic
Read one named fictional inquiry
Read the approved catalogue
Read the approved policy
Show the source names
Not available
Browse the computer
Read email or cloud drives
Search the web
Run arbitrary commands
Why no shell tool?The Customer Inquiry Helper does not need one. A capability should earn its place through the job, not appear because an agent framework can expose it.
The helper sends the fictional inquiry and approved information to Codex with a small output schema. The result must name its status, subject, body, sources, reason, and suggested next step. A schema cannot guarantee truth, but it makes missing fields and unsupported shapes easier for the program to reject.
If the request is missing important information or asks for a promise outside policy, the status must be needs_human and the subject and body must stay empty. That prevents a stopped case from quietly carrying a sendable-looking answer.
Inspect before trustingCan the subject and body be traced to the files? Does the reason explain the boundary? Is the next step modest enough for a person to evaluate?
Run the normal fictional case. The complete proposal appears before the program asks its one consequential question: save this draft locally and record the action? Pressing Enter or answering no changes nothing.
Checkpoint 3 · normal case
npm run demo -- standard
The approval is specific. It is not permission to send, book, edit source information, or approve future drafts. It covers one visible local write. If the draft is weak, decline it and preserve the evidence that the model's proposal was not good enough.
PreviewRead the full draft, reason, sources, and next step.
DecideApprove this write, decline it, or stop to correct the boundary.
WriteOnly an approved draft becomes a local text file and history event.
Approval is not a ritualIf the person cannot reasonably judge the preview, the solution is better evidence or a smaller task—not a brighter approval button.
After an approved save, the helper adds a JSON line to its local activity history. The record includes the time, fictional inquiry, output path, source names, and whether an older draft existed. It does not copy authentication information or hidden model reasoning.
Draft proposed The complete result is visible but nothing has changed.
Person approved The local text file is written and the event is recorded.
History inspected The owner can see which file changed and when.
Undo requested The new file is removed or the prior content is restored, and undo is recorded too.
Checkpoint 4 · evidence and recovery
npm run history
npm run undo
npm run history
Undo is narrow by design: it reverses the most recent un-reversed draft save made by this helper. It does not claim to reverse email, payments, bookings, or a person copying text somewhere else. Real-world recovery must match the real consequence.
The normal case demonstrates the path. The other four cases test whether the boundary survives incomplete, unusual, out-of-area, and urgent requests. A useful failure is one that stops clearly and leaves the person with a sensible next question.
Run any fictional case
npm run demo -- missing
The checkboxes remember progress only in this browser. They are a workshop aid, not evidence that the underlying helper passed. Record the actual proposal or safe stop and discuss what you observed.
Testing questionDid the helper merely avoid a bad answer, or did it explain the boundary well enough for a person to take the next safe step?
When a proposal is wrong, do not immediately add more instructions. First identify which layer failed. The source may be incomplete. The business boundary may be vague. The output shape may accept too much. The model may have ignored a fact. The approval preview may not show enough evidence.
Source problemCorrect the fictional catalogue or policy, then rerun the affected test.
Boundary problemNarrow the job or add a clear stop condition in business language.
Behavior problemKeep the source, add the observed case to the test pack, and compare the next result.
If the deterministic starter tests fail, repair the local program before blaming the model. If those tests pass but the model call fails, preserve the source files and inspect sign-in, the error message, and the structured output. The included troubleshooting tree keeps credential problems separate from application problems.
Checkpoint 5 · local tests
npm test
One improvement at a timeChange one source, boundary, or test assumption, then rerun the relevant cases. Multiple simultaneous changes make it harder to know what helped.
The starter reads local files through its own small functions. That is enough for one local helper. An MCP server may earn its place later when several approved AI clients need the same reusable, well-described access to business information or tools.
A file is enough when
One local helper owns the job
The information is small and stable
No shared interface is needed
A person can inspect the whole boundary
Consider MCP when
Several clients need the same approved access
Inputs and outputs need a reusable contract
Authentication and activity evidence are designed
The connection solves a repeated business problem
MCP does not automatically provide good permissions, correct business rules, authentication, trustworthy information, or safe consequences. Those decisions remain. Our next Field Guide will help an owner decide whether MCP is useful before the later workshop builds a read-only server.
Your practical finishYou can now point to the helper's input, approved knowledge, structured proposal, approval point, activity evidence, tests, and undo path. That understanding matters more than remembering the code syntax.
You can use the starter and handouts independently. If you would like a second pair of eyes, BrainIT can help review one job boundary, test the permission assumptions, or shape a small business-specific prototype after the fictional workshop is clear.