If you’re searching “how to build an AI agent”, you probably want something that actually does work for you: checks things, transforms information, and reports back—without you remembering to ask.
On Zo Computer, an “AI agent” is just a scheduled instruction that runs on your own server. The key difference vs most AI “agents” you see in demos: it can use your files for memory/state, it can call tools (web browsing, scripts, app integrations), and it can run on a schedule.
This tutorial walks through building one end-to-end, then shows how to harden it so it keeps working.
What you’ll build
A practical agent that watches a webpage for changes once per day, saves a snapshot to your workspace, and emails you a short diff.
You can swap the inputs/outputs (check your inbox, summarize news, enrich a spreadsheet, etc.) but the structure stays the same.
Prerequisites
A Zo Computer workspace (files + terminal)
(Optional) Email or SMS integration enabled in Settings, if you want push notifications
Step 1: Pick a single job with a clear “done” condition
Bad agent goals:
“Be my personal assistant”
“Help me with my business”
Good agent goals:
“Every weekday at 9am, check my calendar and email me today’s agenda.”
“Once a day, check this pricing page and notify me if it changed.”
A good AI agent has:
a trigger (when it runs)
inputs (what it reads)
actions (what it does)
an output (where results go)
Step 2: Choose the trigger (schedule) and delivery method
In Zo, Agents run on a schedule you define (daily, hourly, weekdays, etc.) and can deliver results via:
Email (best for summaries you’ll search later)
SMS (best for short, urgent alerts)
Files (best for agents that build persistent state or feed other workflows)
You can change delivery later. Pick one now so the agent has a crisp “contract”.
To learn the mechanics of creating an Agent, see: https://docs.zocomputer.com/agents
Step 3: Write the instruction like a program (but in English)
The biggest reason agents fail is vague instructions.
Use this template:
State the goal in one sentence.
List the exact inputs (URLs, files, folders).
Describe the steps, in order.
Specify the output format and where to write/send it.
Add guardrails (timeouts, max items, what to do on error).
Here’s a concrete instruction you can paste into an Agent:
Every day at 8am:
Read https://example.com/changelog using the fastest method available.
Save the page text to file 'AgentState/changelog-latest.txt'.
If file 'AgentState/changelog-prev.txt' exists, compare the new text to the previous text and summarize what changed (max 10 bullets).
If there were meaningful changes, email me a short summary and include the most relevant quoted lines.
Copy 'AgentState/changelog-latest.txt' to 'AgentState/changelog-prev.txt'.
Constraints: if the page can’t be fetched, send a short error email and do not overwrite the previous snapshot.
Implementation notes for web reading (so the agent chooses the right tool):
For fast extraction: https://docs.zocomputer.com/tools/read-webpage
For pages that need login or heavy rendering: https://docs.zocomputer.com/tools/view-webpage
Step 4: Give the agent a place to store state (this is “memory”)
If you want an agent to notice changes, dedupe work, or continue where it left off, it needs state.
On Zo, the simplest state is just files. Create a folder like:
file 'AgentState'
Common state patterns:
“last run” timestamp in a text file
previous snapshot of a webpage
a small JSON file that stores counters, IDs already processed, etc.
This is the difference between a one-off automation and an agent that can run forever.
Step 5: Test once manually before you schedule it
Before relying on a daily/weekly schedule, run the instruction once and make sure:
it produces the expected output
it writes/updates the correct files
it handles the “no changes” case without spamming you
When testing, keep scope small:
1 URL, not 20
1 inbox label, not your whole email
max 10 items
Step 6: Add failure handling (so it doesn’t silently rot)
Real systems fail: rate limits, 500s, layout changes, expired auth.
Add explicit behavior for the failure modes you care about:
If a fetch fails → send an error message and keep the old snapshot
If the diff is too large → summarize the top changes only
If the agent takes too long → stop and report partial progress
Also add a “don’t spam me” rule:
Only notify when there’s meaningful change
Otherwise write a short log line to a file and exit
Step 7: Iterate: upgrade from “one agent” to a small system
Once one agent works, you can compose:
A watcher agent that writes changes into file 'AgentState/changes.md'
A weekly digest agent that reads that file and emails a summary
A maintenance agent that archives old snapshots monthly
If you want more examples of agent design patterns, these tutorials are good next steps:
https://www.zo.computer/tutorials/how-to-automate-tasks-with-ai
https://www.zo.computer/tutorials/how-to-build-ai-agents-without-coding
Summary
To build an AI agent that keeps working:
Start with one job and one output
Write instructions with explicit inputs/steps/constraints
Store state in files so the agent has “memory”
Test once, then schedule
Handle failures and prevent notification spam