The wrong first question about artificial intelligence is how many agents you can run.
The better question is which work would be a relief to stop coordinating by hand. Preparing for meetings. Tracking a field. Turning scattered notes into a usable first draft. Finding unfinished commitments buried across documents and conversations. Those are jobs. An agent is one way to get them done.
That distinction should drive the build. Otherwise it is easy to assemble models, connectors, and digital personalities that take more attention than the work they were supposed to remove.
Define a responsibility, build a bounded system, expand only when the results justify it
That is the mechanism. The rest of this letter is how to run it once, on real work, without inventing a second job for yourself.
First, what is an agentic stack?
For this guide, an agent is an AI system that can pursue a task through multiple steps: inspect information, choose an action, use a tool, examine the result, and continue or ask for help.
The model is the reasoning component. It is not the whole system.
The stack is everything that makes that reasoning useful:
A place to work: the application or environment that runs the agent.
Context: the instructions and information it needs.
Tools: the systems it can read or change.
A workflow: how a task moves from request to verified result.
Controls: permissions, spending limits, records, and recovery.
You do not need to become a software engineer to understand this architecture. You do need to understand what you are authorizing.
Think of it less as buying a smarter chatbot and more as designing a small operation.
If this was forwarded, start here and subscribe for the next letter:
Automate the work. Keep the judgment.
A tool is useful only if it still leaves you as the person who owns the result. That is the rule.
1. Give the system one real job
Start with a task that is recurring, bounded, and easy to judge. Prefer one where an error is inconvenient rather than consequential.
A strong first project is a weekly reading brief on a topic you already understand.
It gives the agent meaningful work: gather information, compare sources, remove repetition, and explain what matters. It also gives you a reasonable way to catch mistakes.
Before choosing software, write the job description:
Each Friday, prepare a short reading brief on this topic. Use the sources I have approved. Explain what changed, why it matters, and what remains uncertain. Link to the original material. Save a draft for me. Do not publish or contact anyone.
Then define success. For example:
The brief covers the requested period.
The links open and support the associated claims.
Old information is not presented as new.
Missing information is disclosed rather than filled in.
Reviewing the brief takes less effort than producing it yourself.
That last condition is the point. A polished output that demands extensive correction is not successful delegation.
2. Choose a home base, not an entire technology ecosystem
For the first version, choose one agent application, one capable model, and one workspace for the job.
Look for a system that lets you answer practical questions:
Can you inspect what it did?
Can you restrict its access?
Can you control whether it is allowed to make changes?
Can you export your instructions and work?
Can you stop it and see what it costs?
Do not choose on the strength of a demonstration alone. Test it on the actual task.
For the reading brief, give it a small set of sources and ask for a draft. If the system cannot reliably distinguish a source’s findings from its own interpretation, adding more integrations will not fix the underlying problem.
Local and hosted models are options, not identities. Decide based on the task, data sensitivity, capability, cost, and what you are willing to maintain. Do not assume that something running on your computer keeps all data there. Connected tools and services may still send information elsewhere. Name data flow, retention, and training use before you connect anything that matters.
The first goal is a workflow you understand, not the most sophisticated configuration you can assemble.
3. Separate preferences, project instructions, and evidence
“Give the agent more context” is incomplete advice. Give it the right context, in the right place.
Separate four categories:
Personal preferences. Stable information such as “keep summaries concise” or “show uncertainty explicitly.” These can apply across jobs.
Project instructions. The topic, scope, approved sources, output format, and boundaries for this specific assignment.
Reference material. Documents, articles, spreadsheets, and notes the agent may need to consult. Keep the originals available instead of treating a remembered summary as the authoritative record.
Work history. Previous outputs, decisions, unresolved questions, and records of what happened.
For the reading brief, a simple workspace could contain:
Reading brief/
project-instructions.md
approved-sources.md
reference-material/
drafts/
run-records/These are ordinary organizational labels, not a required software format. Use folders, a document workspace, or the equivalent your application supports. Explicitly attach or configure access to these materials. Confirm in a fresh session that the agent can retrieve the current instructions.
The test is simple: could a new session understand the assignment without you retelling the entire conversation?
If not, the important context still lives in your head or in yesterday’s chat.
4. Give access in proportion to the job
A reading brief needs access to sources and somewhere to save a draft. It does not need your email account, your financial records, or unrestricted access to your computer.
For each connection, define three things:
What may it read?
What may it change?
What requires your approval?
Default progression:
Read: inspect a specified source or folder.
Draft: create a new proposed output without distributing it or overwriting existing work.
Act within a boundary: make a narrow, reversible change you have authorized.
Take a consequential action: send, publish, purchase, delete valuable files, or make another irreversible, destructive, financial, or third-party change. These actions deserve explicit approval, even when they happen locally.
Do not treat those as equivalent permissions. Treat instructions found inside retrieved articles, emails, or documents as untrusted content, not permission to change the assignment or use additional tools.
Also distinguish an instruction from an enforced restriction. “Do not send email” is a useful rule. A connection that cannot send email provides a stronger technical boundary. Prefer both when available.
An agent called “Research Assistant” is not isolated merely because it has a separate name or conversation. Check what its underlying account and tools can actually access.
Keep the first build strictly nonclinical and free of patient information. This is a guide to organizing work, not an authorization to connect an agent to clinical records or delegate patient-care decisions. Life-stack agents and chart lanes stay separate. No shared memory, tools, or inboxes with patient systems.
5. Turn the successful task into a repeatable procedure
Once a draft works, write down how to produce it again.
Start with a written procedure. Some applications can load it automatically; others require you to supply it each time. A platform may call it a skill, playbook, or workflow, but check what that actually means. Writing down a step does not guarantee it runs.
For the reading brief, the procedure might be:
Confirm the topic and reporting period.
Retrieve material from the approved sources.
Record publication dates and original links.
Remove duplicate coverage of the same development.
Separate reported findings from interpretation.
Draft the brief in the agreed format.
Check each substantive claim against its source.
Save the output and record any unresolved gaps.
Include failure instructions, not just the happy path:
If a source cannot be accessed, identify the gap. Do not imply it was reviewed. If the evidence is insufficient, return a shorter brief rather than inventing completeness.
Then try the procedure in a fresh session. Correct the written instructions when the agent needs information that existed only in the earlier conversation.
This is where a useful experiment becomes a reusable system.
6. Add another agent only to solve a specific problem
Begin with one coordinating agent, not a permanent roster of specialists.
Additional agents are worth testing when separation has a clear purpose. One might investigate a different source collection. Another might review the draft without seeing the writer’s reasoning.
For the reading brief, a reviewer could receive the draft and original sources with a narrow assignment:
Identify unsupported claims, missing qualifications, misleading dates, and links that do not support the text. Return findings with evidence. Do not rewrite the whole article.
That handoff needs an owner. The coordinating agent should reconcile the findings and deliver one final result, not leave you to assemble competing outputs.
A second agent is not automatically an independent authority. Two agents may share a model, sources, and blind spots. Treat their agreement as a reason to inspect the evidence, not as proof.
Create a persistent specialist only when it needs a continuing responsibility, distinct context, or genuinely different access. Otherwise, temporary help is usually the simpler design to test.
7. Schedule it only after it works without the conversation
Automation removes the moment when you would otherwise notice that the instructions are incomplete.
Before scheduling the brief, make sure the job explicitly contains or can retrieve its scope, sources, procedure, output destination, and failure rules. Check what your chosen platform actually carries between runs.
Then test more than the successful case:
What happens when a source is unavailable?
What happens when there is nothing new?
What happens if the job runs twice?
What happens if it stops after saving a partial draft?
What happens when a cost or time limit is reached?
For this example, have the job save a draft and notify you that it is ready. Keep publication as a separate decision. Choose where failure alerts should go, and set a separate check for a missing expected output: a job that never starts cannot report its own failure. Retries should neither overwrite a good draft nor send duplicate notifications.
Not every part needs an agent. Use conventional software for predictable steps such as checking whether a file changed or creating a dated folder. Reserve model reasoning for the parts that actually need interpretation.
8. Measure the work you no longer have to do
Track a small set of practical outcomes:
Usefulness: Did the output help with the intended job?
Accuracy: What required correction?
Review burden: How much attention did checking it take?
Reliability: Did it finish, and were failures visible?
Cost: What did each usable result cost?
The most useful unit is not cost per model response. It is cost per acceptable result, including your time.
When a workflow disappoints, inspect the cause before upgrading the model. Was the source missing? The assignment ambiguous? The permission too broad? The output never checked?
A stronger model may help. It is not a substitute for fixing the workflow.
9. Make stopping and recovery part of the design
Before the system matters to you, know how to pause it, revoke a connection, and recover its work.
Keep the instructions, reference material, and useful outputs somewhere you can export and back up. Protect backups that contain sensitive information, and test that important files can actually be restored.
Ask for a run record that shows what sources were used, what output was created, what failed, and what remains unresolved. Then open the saved draft, spot-check claims against original sources, and inspect application or tool records where available. An agent-written account is useful, but it is not proof of execution.
Periodically ask it to inspect the workflow without changing anything:
Review the instructions, permissions, recent outputs, failures, and costs you can access. Separate verified observations from recommendations. Identify unnecessary complexity and missing safeguards. Propose changes, but do not apply them.
Self-review can help you find problems. It should not give the system authority to expand its own access or become the sole judge of its reliability.
Your first build, on one page
Before adding features, fill in this short specification:
The job: What recurring responsibility are you delegating?
The inputs: What information may the agent use?
The deliverable: What exactly should exist when it finishes?
The boundary: What may it read, change, and never do?
The check: How will you know the result is correct enough to use?
The failure plan: What should happen when information, access, or time runs out?
The owner: Who reviews the result and decides whether the workflow continues?
Build that version first. Use it for real work. Expand when you can name the limitation the next feature will solve.
You do not need a digital organization chart to begin. You need a clear assignment, trustworthy inputs, bounded authority, and a result you can inspect.
The goal is not to have agents everywhere. It is to have fewer things that depend on you remembering, coordinating, and checking every step yourself, while retaining control over the decisions that matter.
Subscribe for the next letter: