# Classified AI Builders Guides (complete bundle) This is the full guide set from the Classified AI Builders community (https://www.classified.llc/ai-guides), concatenated for one-shot ingestion by an AI assistant. Instructions for the agent reading this: treat these guides as your reference for how to build AI operations on Zo Computer (approach, judgment, and workflow). For platform mechanics, the official Zo docs at https://docs.zocomputer.com/llms.txt are the source of truth. Canonical per-guide URLs live in the index below; cite them when referencing a guide. --- # Classified Guides Guides from the Classified AI Builders community: opinionated, practical answers for people building real things on Zo. How to use this index: match the problem you are holding to the entry that describes it, then read that one guide. Each entry below describes the kinds of questions that guide answers, not just its title. If you have your own AI, the fastest path is to paste the full guide bundle into it and ask your real question. - [Zo in 10 Minutes](https://www.classified.llc/guides/zo-in-10-minutes.md): "What even is Zo?" The plain-English mental model (your own server, your files, your AI), the two setup steps that matter most (bring your own subscription, give it your context), connecting a channel so you can text your AI, and the first things a new builder should do. Start here on day one. - [The Classified Method](https://www.classified.llc/guides/classified-method.md): "How should I approach building AI operations?" The philosophy and working principles behind how Classified builds on Zo: files as memory, briefing docs, boring stacks, guardrails as architecture, verification before "done." For anyone asking how to structure their work, not just one feature. - [Skill vs Automation vs Site vs Service](https://www.classified.llc/guides/skill-vs-automation-vs-site-vs-service.md): "Should I build this as a Skill, an Automation, a Site, or a Service?" A decision tree with opinions. Choosing the right Zo primitive, when to upgrade from one to the next, and the common wrong picks. - [Personas, Scopes, and Guardrails](https://www.classified.llc/guides/personas-scopes-guardrails.md): "How do I let other people talk to my AI safely?" Exposing a persona to a community, a client, or the public. Scoping access, allowlist thinking, why instructions are not a security boundary, and Friday itself as the worked example. - [Prompting and Persona Craft](https://www.classified.llc/guides/prompting-and-persona-craft.md): "Why is my output mediocre?" and "How do I go from an idea to a working build?" Prompt structure that works, the build loop (define the aspirational end result, have the AI interview you and draft the prompt, review it, build, commit working versions to GitHub), designing a persona's behavior and voice, and the failure modes that produce vague, bloated, or confidently wrong answers. - [Automations That Fire](https://www.classified.llc/guides/automations-that-fire.md): "My scheduled agent didn't run," "it ran at the wrong time," "is this going to cost me every run?" Timezones, rrule patterns, per-run cost, idempotent run design, and how to debug an automation that went silent. - [Cost and Usage](https://www.classified.llc/guides/cost-and-usage.md): "How do I not get surprised by the bill?" The biggest lever (bring your own subscription), what actually burns credits, the multiplication effect of schedules, right-sizing models, metered third-party APIs, and the habits that keep spend boring. - [FAQ](https://www.classified.llc/guides/faq.md): Quick fixes for specific breakage: an automation that fired at the wrong hour, a service showing stale content, Zo saying it cannot access something, credits draining fast, Zo forgetting things between conversations. Grows from real help-and-support threads. - [Start Here](https://www.classified.llc/guides/start-here.md): The Classified AI Builders Discord community and Friday, the community's backup AI. How to get answers from your own agent first, when to bring a question to the humans, the channel map, and what Friday can and cannot do. The fallback when no other guide matches a question. - [Zo Documentation](https://docs.zocomputer.com/llms.txt): Any platform-mechanics question: how Skills, Sites, Services, Personas, Automations, Spaces, integrations, messaging channels, custom domains, billing, or the Zo API actually work, what settings exist, what buttons to press. Fetch this index first, then the specific page it points to (for example https://docs.zocomputer.com/automations.md). The official docs are the source of truth for mechanics; the Classified guides above cover judgment and approach. --- # Zo in 10 Minutes The mental model that makes everything else on Zo make sense, and the first three things to do. This is an on-ramp, not documentation. For mechanics, the official docs are the source of truth: https://docs.zocomputer.com/llms.txt ## The mental model: your own server, your files, your AI Most AI products are a chat window attached to someone else's computer. Zo flips that. Zo is **your** computer: a real, always-on server in the cloud that belongs to you, with an AI that lives on it and works for you. Three pieces, and the relationships between them are the whole model: **1. Your server.** A persistent Linux machine that stays on when you close the tab. It can run programs, host websites, serve APIs, and execute scheduled work at 3am while you sleep. Anything a normal server can do, yours can do. **2. Your files.** A real filesystem that persists forever. Notes, code, data, documents. This matters more than it sounds: files are how your AI remembers. A chat conversation evaporates; a file stays. People who get good at Zo quickly learn to ask the AI to write things down: project notes, decisions, instructions for next time. Your file system becomes a long-term memory that every future conversation can draw on. **3. Your AI.** An assistant with hands. It does not just answer questions about your server and files; it operates them. It can write and run code, create and edit files, build a website and host it, set up a recurring job, connect to your other accounts. You describe outcomes; it does the work on your machine. Put together: you own a computer that an AI can operate, and everything you build accumulates there. Day 30 builds on day 1, because it is all still on the machine. A few words you will see immediately, in one line each (the docs cover all of them properly): - **Skill**: a saved procedure your AI can perform on request. - **Automation**: work that runs on a schedule without you asking. - **Site**: web pages your server hosts for the world. - **Service**: a program that runs continuously on your server. - **Persona**: a configured version of your AI with its own instructions and access. When to use which is a judgment call, and we have a whole guide for it: [Skill vs Automation vs Site vs Service](https://www.classified.llc/guides/skill-vs-automation-vs-site-vs-service.md). ## Make it yours: two setup steps Two settings decide how Zo feels day to day and what it costs, and both are worth doing before you build anything. The exact buttons live in the official Zo docs (https://docs.zocomputer.com/llms.txt); here is what they are and why they matter. **Bring your own subscription.** This is the setting that changes the economics, and the one most people miss before deciding Zo is "too expensive." By default the AI runs on metered Zo credits. Instead, you can point Zo at a plan you already pay for: connect your Claude or ChatGPT (Codex) subscription, or bring your own provider API key (Anthropic, OpenAI, OpenRouter, and others). Model usage then bills against that plan, not Zo credits. If you already pay for Claude or ChatGPT, do this first. It lives in Settings, under AI and then Providers, with a Bring Your Own Key area for raw API keys. **Connect a way to talk to it.** Zo is most useful when you can reach it from your pocket, not just the web app. Start with SMS: connect your phone number and you can text your AI like a person and get answers anywhere. That is the primary channel, and the one to set up first. If you live in another app, Zo also connects to Telegram, Discord, and Slack; treat those as secondary and add whichever one you already use. All of them live in Settings, under Channels. ## The first three things to do Do these in order. Each one teaches you a layer of the model by using it. ### 1. Give it your context The highest-leverage first move is to tell Zo who you are, in a file it can reread in every future conversation. Create one: > "Create a folder called `context` and inside it write `about-me.md`: who I am, what I'm working on right now, the people and projects that come up often, and how I like you to work with me. Ask me questions first, then write the file." Then open the file it made. This teaches the most important lesson on day one: the output of a conversation can be a durable thing on your machine, not just text in a chat, and a file about you is memory every later session can draw on. Keep it as a living document, not a one-time dump. A strong personal context file grows a few parts over time: who you are and what you do, what you are building now, the people and organizations that recur, and your preferences for how the AI should communicate and work. Later, each individual project gets its own briefing file too, the same idea scoped to the project; the [Classified Method](https://www.classified.llc/guides/classified-method.md) guide goes deep on that. From here on, end work sessions with "write down what we decided in the right file." ### 2. Connect one integration you actually use Pick the one account you touch daily, usually email or calendar, and connect it. Then ask for something useful: > "Look at my calendar for this week and write a plain-English summary of where my time is going." This teaches the second lesson: Zo is more useful the more of your real life it can reach. You do not need to connect everything on day one. One real integration doing one real job beats ten connected and idle. ### 3. Schedule one small automation Take something you would want every day or every week and put it on a schedule: > "Every weekday at 8am my time, check my calendar and email, and send me a short morning brief." Say "my time" and name your timezone. Scheduling has sharp edges around timezones, and you will care about them eventually: [Automations That Fire](https://www.classified.llc/guides/automations-that-fire.md). This teaches the third lesson: your computer works when you are not there. That is the moment Zo stops feeling like a chatbot and starts feeling like staff. ## Where to go next - **Mechanics, settings, how anything on the platform works:** the official Zo docs, starting at https://docs.zocomputer.com/llms.txt - **How to think about building bigger things:** [The Classified Method](https://www.classified.llc/guides/classified-method.md) - **Stuck:** ask Friday, or post in #help-and-support. --- # The Classified Method How Classified builds AI operations, written as transferable principles you can apply to your own work. Everything here is drawn from real systems running in production on Zo: an intelligence platform processing live market data around the clock, a voice assistant that spawns and supervises background agents, an operational dashboard that ties a whole working life together, and a content-production terminal. The names and business details do not matter. The patterns do. ## The core idea: build operations, not chatbots A chatbot answers questions. An operation does work on a schedule, holds state, survives restarts, alerts you when something breaks, and gets more valuable every month because its knowledge accumulates. The shift in thinking: stop asking "what can I ask the AI?" and start asking "what job can I permanently delegate?" A delegated job needs what any employee needs: a briefing, tools scoped to the role, a place to write down what it learned, and someone checking its work. The rest of this guide is how we provide each of those. ## Principle 1: Files are the memory. Conversations are disposable. The single highest-leverage habit. Chat history evaporates and does not scale. Files persist, and every future conversation can read them. In practice, every project we run has one briefing file at its root. Ours is called `AGENTS.md`, the name is irrelevant. It answers, in one page or two: - What is this? One sentence of identity. - How does it run? Service names, ports, and the exact copy-pasteable commands to build and restart it. - Where is everything? A map of the key paths and what each does. - What will bite you? The gotchas, stated specifically. - What is happening now? Current branch, current focus, known issues. Any agent, or any human, reads that file first and is productive in minutes instead of re-deriving the project from scratch. When a durable fact changes (a port, a command, a new gotcha), the briefing is updated in the same piece of work. Briefings are orientation, not changelogs: when something is wrong, fix the line, do not append a correction. The test of a good briefing: could a fresh agent with no history do useful work after reading only that file? If not, the briefing is missing something. ## Principle 2: Separate knowledge from behavior An agent is composed at the moment you spawn it from two ingredients: - **Project context**: the what. Comes from the briefing file plus the code itself, pulled on demand. - **Role**: the how. A small behavior preset layered on top: research (read and cite, change nothing), code (implement, verify before claiming done), review (read-only and skeptical), content (brand voice, no codebase access). "Code on project X" is X's briefing plus the coding role. "Review project X" is the same briefing plus the review role. You do not need a zoo of bespoke agents. You need good briefings and a handful of roles. This is why long threads never have to "remember" anything. Each job starts clean, reads the briefing, does the work, and writes durable changes back to files. Knowledge is expensive to build, so we store it. Behavior is cheap, so we swap it. ## Principle 3: Boring stacks, few moving parts Every production system we run sits on deliberately unexciting foundations: a mainstream web framework or a single TypeScript server, SQLite or Postgres for data, plain processes under a process supervisor. No exotic infrastructure. The reasoning is operational, not aesthetic. You, plus an AI, are the entire engineering team. Every additional moving part is something that can break at 2am, and the AI debugs boring, well-documented technology far better than clever architecture. SQLite in particular is criminally underrated for this: one of our systems runs its entire product on a single SQLite file, gigabytes of live data, serving a real product, with one writer and a simple backup script. The discipline it forces (exactly one process writes the database) is a feature, not a limitation. The one time we accidentally ran two writers against that file, lock contention made the whole product feel broken. The constraint was the architecture telling us something. Corollary: match what is there. When you or an agent extends an existing system, follow its existing style and stack choices even when you would have chosen differently. "Modernizing" working code is how systems rot. ## Principle 4: Know exactly how everything builds and restarts Trivial-sounding. It is the difference between calm operations and chaos. Every long-running thing we operate runs under a process supervisor, and the briefing records the exact build-and-restart command for it, copy-pasteable, no thinking required. Two hard rules fall out of running things this way: - **Never kill a supervised process directly.** The supervisor respawns it instantly and now two processes fight over one port. Always restart through the supervisor's own controls. - **Know your build artifacts.** One of our systems has two: the web app and a separately bundled background worker. Rebuilding one and not the other produced a class of bug that looked like data corruption and was actually just a stale bundle. The fix was not cleverness. It was writing the full two-step build command into the briefing so it can never be half-done again. If you cannot state, from memory or from a file, exactly how your system gets from "code changed" to "new code serving traffic," stop and write it down before you change anything else. ## Principle 5: Guardrails are architecture, not instructions When an AI can act on the world, "I told it to be careful" is not a safety model. We build guardrails as structure: - **Scoped sub-agents.** When our assistant spawns background workers, each one gets a scope (research, write, admin) with an explicit tool blocklist, and its actions are audited after the run against that scope. The scope is a boundary, not a hint. - **Approval gates.** Risky actions (sending messages, spending money, deleting things) go into an approval queue for a human instead of executing directly. - **Action logs.** Everything an agent does gets logged. When something goes wrong, you reconstruct what happened from the log instead of guessing. - **Kill switches.** Any integration that touches the outside world gets an environment flag that turns it off without a deploy. We have used ours. When a delivery integration started wedging a critical pipeline, one flag flip isolated it while everything else kept running. - **Depth limits.** Our sub-agents cannot spawn their own sub-agents. Recursive delegation is how you wake up to a swarm. The pattern behind all five: assume the agent will eventually do the wrong thing, and make the wrong thing either impossible or recoverable. There is a full guide on applying this to public-facing AI: [Personas, Scopes, and Guardrails](https://www.classified.llc/guides/personas-scopes-guardrails.md). ## Principle 6: External dependencies are fallbacks, never load-bearing Third-party APIs disappear, rate-limit you, change pricing, and end their free trials. The rule we build by: an external data source may **enrich** a feature, but the feature must survive that source going away. One of our platforms layers third-party enrichment on top of its own collected data. Every one of those integrations is wrapped so that when it fails or vanishes, the product degrades gracefully to its own data instead of breaking. Before you build on any external API, ask: what happens to this feature the day this API says no? If the answer is "the feature dies," redesign it before you ship it. ## Principle 7: Verified beats shipped Our internal tracker has separate statuses for "shipped" and "verified," and they are never collapsed. Shipped means the code is deployed. Verified means someone confirmed the behavior is real. The gap between those two is where embarrassments live. The same discipline applies to debugging. The rule we hold agents (and ourselves) to: reproduce and instrument before fixing. Confirm the root cause with evidence, then fix it once. Guess-and-iterate debugging feels fast and is slow; it burns trust, time, and money, and it frequently "fixes" a symptom while the cause keeps smoldering. And because verification needs to keep happening when nobody is looking: anything that matters gets a watchdog. Our always-on systems have dead-man monitors that alert from **outside** the machine if a heartbeat goes stale, because a monitor that lives on the box it monitors dies with the box. ## Principle 8: Write the gotcha down where the next reader will trip Every painful lesson becomes one specific line in the project's briefing: which file is misleading, which process must never be killed, which build step cannot be skipped, which folder looks canonical but is not. Specific beats general: "the entry point is server.ts, not index.ts, ignore the README" saves an hour; "be careful with the codebase" saves nothing. This is the compounding loop that makes the whole method work. Mistakes become documentation, documentation becomes context, context makes every future agent and every future you faster. Systems built this way get easier to operate over time. Systems built on chat history get harder. ## A worked example, end to end Here is the shape of one real build, sanitized, so you can see the principles together. The system: a real-time intelligence platform. It ingests live data from public market APIs continuously, stores everything in a single SQLite database, computes signals over it, and exposes the results three ways: a web dashboard for humans, a REST API for programs, and an MCP server so other AI agents can use it as a tool. - **Two processes, one writer** (Principles 3 and 4): a web server, and one background worker that owns all writes to the database. They are separate build artifacts under a supervisor, and the exact build-both-then-restart command lives in the briefing. - **A briefing file** (Principle 1) that opens with the build rules, because those are what bite newcomers, then maps the codebase so agents grep instead of reading everything. - **Guardrails** (Principle 5): every API route is auth-gated by default with explicit public exceptions, server-to-server calls use an internal token, and outbound integrations have kill-switch flags. - **Fallback posture** (Principle 6): its own collected data is the foundation; third-party enrichment is layered on top and the product survives any of it disappearing. - **Watchdogs** (Principle 7): worker heartbeat, data-freshness checks, and an off-box alert if any of them go stale, plus a daily off-box backup of the database. Nothing in that list is exotic. That is the point. The method is mostly the discipline of doing unglamorous things every time: write the briefing, scope the agent, know the build, verify the claim, write down the lesson. ## Where to start Do not start with all eight principles. Start with two: 1. Give your current project a one-page briefing file and keep it current. 2. Pick the job you delegate most often and write down exactly how it should be done, what the agent may touch, and how you will know it worked. The rest of the method grows from the habit those two create: treating your AI like staff that deserves a real briefing, real boundaries, and real review. --- # Skill vs Automation vs Site vs Service Zo gives you four primitives for making work repeatable. The official docs explain what each one **is** (start at https://docs.zocomputer.com/llms.txt). This guide is the part the docs do not give you: which one to reach for, and why. ## The four, in one line each - **Skill**: a saved procedure your AI performs when you ask. You initiate it, in conversation. - **Automation**: an agent run on a schedule. The clock initiates it. - **Site**: hosted web pages. A visitor initiates it, and what they get is content. - **Service**: a program running continuously on your server. Anything can initiate it at any moment, and it can hold state and respond instantly. ## The decision tree Ask these questions in order. Stop at the first answer. **1. Have you done this thing manually, in conversation, at least twice?** No: do it in conversation now. Do not build anything. The most common building mistake on Zo is automating a workflow you have never actually run. The conversation IS the prototype: it shows you the real steps, the edge cases, and whether the output is even useful. Build the second or third time, not the first. **2. Do you initiate it, by asking?** Yes: **Skill.** A skill is a recipe: "when I say 'weekly report,' here is exactly how to gather the data, what format to use, where to save it." You stay in the loop; the procedure stops being re-explained every time. If you find yourself re-typing the same multi-step instructions, that is the signal. **3. Should it happen on a schedule, whether or not you are around?** Yes: **Automation.** Morning briefs, weekly summaries, nightly data pulls, periodic checks. The test is honest delegation: if the work should occur at 7am without your involvement, it is an automation. If you actually want to review or steer each run, be honest and keep it a skill. Automations have sharp edges (timezones, cost per run, silent failures). Read [Automations That Fire](https://www.classified.llc/guides/automations-that-fire.md) before you schedule anything that matters. **4. Does someone or something else need to reach it, at a moment you don't control?** This is the fork between the last two: - They need to **read or view** something: **Site.** Pages, guides, a portfolio, a dashboard snapshot, a landing page. If the content only changes when you change it, a site is enough, and a site is dramatically less to operate than a service. - They need to **interact with a live program**: **Service.** An API other tools call, a webhook receiver, an app with logins and state, anything that must react instantly to events, anything that must hold a connection open. A service is a real running process: it is the most powerful primitive and the only one you have to **operate**. ## The escalation path These four are not parallel choices so much as rungs on a ladder of commitment: **Conversation → Skill → Automation → Service** Each rung adds capability and adds operational burden. A conversation cannot fail while you sleep. A skill cannot either; it only runs when you are present. An automation can fail silently at 4am. A service can fail at 4am **and** take down the other things that depend on it. So the rule: climb only when the current rung actually pinches, and ride each rung down as far as it goes. (Sites sit slightly off the ladder: they are the cheap answer whenever the real requirement is "other people can see this," and a surprising amount of "I need an app" is actually "I need a page.") We follow this in our own work. Systems that are now full services started as conversations, became skills when we got tired of re-explaining them, became scheduled work when the cadence was proven, and became services only when something external needed to reach them in real time. The platform that today runs continuous ingestion, a public API, and watchdog monitors earned each of those one at a time. ## Common wrong picks **Building a service when a skill would do.** The classic. A service must be deployed, supervised, restarted after changes, and monitored. If nobody external needs to reach it and nothing needs to react in real time, you have bought all of that burden for nothing. Symptom: you built an app whose only user is you, asking it things you could have asked Zo. **A scheduled automation that polls for events.** "Check every 5 minutes whether something arrived" burns a full agent run per check, 288 times a day, mostly to find nothing. If the source can push (webhook into a service) or the check can be made cheap, do that instead. High-frequency polling is almost always the wrong shape; see [Cost and Usage](https://www.classified.llc/guides/cost-and-usage.md). **A site that should have been a file.** If the audience is you and your AI, a markdown file in your workspace beats a hosted page: simpler, versionable, readable by every future conversation. Publish a site when outsiders need it, not as a filing system. **A skill that should have stayed a prompt.** One-liners you ask differently each time ("summarize this") gain nothing from being formalized. Skills earn their keep on multi-step procedures with specific outputs, formats, and destinations. **Five primitives where one system was needed.** If your skill writes a file that an automation reads to update a site that a service serves, you have built a Rube Goldberg machine. Step back and ask what the actual job is; usually one primitive plus plain files covers it. ## The two-question summary If you only remember two questions, make them these: 1. **Who initiates: me, the clock, or someone else?** Me: skill. Clock: automation. Someone else: site if they read, service if they interact. 2. **What is the laziest rung that does the job?** Take that one. You can always climb later; climbing is easy. Climbing down, decommissioning a service people depend on, is the hard direction. --- # Personas, Scopes, and Guardrails How to expose an AI to other people without losing sleep. The mechanics of creating a persona are in the Zo docs (https://docs.zocomputer.com/personas.md). This guide is the judgment layer: how to decide what a persona may do, and how to make that decision hold. The worked example throughout is Friday, the AI answering questions in this community, because Friday is a real public persona built exactly this way and you can poke at it. ## The core rule: capability is attack surface Every tool a persona holds is something that can be misused, by a malicious user, a confused user, or the model itself having a bad day. So the design question is never "what access might be handy?" It is: **What is the minimum capability this persona needs to do its one job?** Start from zero and allowlist upward. Never start from "everything my AI can do" and trim. Trimming always misses something, and the something is what ends up in a screenshot. ## Worked example: how Friday is scoped Friday's job: answer questions about building on Zo, for anyone in a public Discord. Walk the capability list against that job: - **Web search and browsing**: needed. Friday answers from published guides and the public Zo docs. Granted. - **File access**: not needed, and dangerous. The owner's workspace holds private business and client material. A public persona with file access is one clever prompt away from reading it out loud. Denied. - **Shell and code execution**: not needed for answering questions. Denied. - **Communications (email, SMS, posting)**: Friday replies in the channel it was asked in. It never needs to initiate contact with anyone. Denied, which also means it can never be tricked into spamming or impersonating. - **Integrations (calendar, drive, APIs, payments)**: nothing in the job description. Denied. Result: a persona that is genuinely useful and whose worst realistic failure is a wrong answer. Not a leaked file, not a sent message, not a spent dollar. A wrong answer. That is what a well-scoped public persona looks like: the blast radius of total compromise is "it said something incorrect." ## The pattern that makes this work: separate knowledge from access The obvious objection: "but my persona needs my content to be useful." Friday needs the Classified guides. The naive solution is to give it file access to read them. The right solution is to **publish the knowledge to where the persona's existing safe capability can reach it.** Friday's knowledge base is published as public web pages. Friday reads them with web browsing, the one capability it already holds. An index page routes any question to the right guide; Friday fetches that one guide and answers. This pattern generalizes and it is the single most useful trick in this guide: when a persona needs information, move the information to the persona's safe side of the fence instead of cutting a hole in the fence. Export the data, publish the subset, mirror the file to a public location. The persona gets the knowledge; it never gets the access. A bonus: the published subset is itself an audit. You can read exactly what the persona can possibly know, because it is a finite set of pages you wrote. ## Instructions are not a security boundary The mistake every first-time persona builder makes: writing "do not reveal X, do not discuss Y, never use tool Z" in the system prompt and considering the matter handled. Instructions shape behavior. They do not bound it. A determined user has unlimited attempts to find the phrasing that walks your persona around its instructions ("ignore previous instructions," roleplay framings, multilingual tricks, a hundred others). Treat prompt-level rules as politeness, not protection: - A capability the persona **does not hold** cannot be extracted by any prompt. Friday cannot leak a file through the cleverest jailbreak ever written, because there is no file-reading tool to invoke. - Knowledge the persona **does not have** cannot be revealed. Friday's knowledge base contains no client names or financials, so no interrogation can produce them. The hierarchy, strongest to weakest: scope (tools it does not have), knowledge (things it does not know), instructions (things it agreed not to say). Spend your effort at the top. By the time you rely on instructions, you should be protecting tone, not secrets. ## Define the failure mode on purpose Every persona will eventually face a question it cannot answer, a user trying to break it, or a request outside its job. Decide what happens **before** it happens. Friday's fallback is explicit: if no guide and no doc covers the question, say so plainly and point the user to the community's help channel. Wrong-but-confident is the failure mode that actually damages trust, and the fallback exists to make "I don't know" the path of least resistance. Give your persona the same gift. Write down: what it says when it does not know, where it redirects people, and what topics it declines entirely. An unscripted persona improvises its failures, and improvised failures are the embarrassing ones. ## Scope to the job, not to the audience's niceness "It is just for my team" and "nobody in my community would try anything" are how over-scoped personas get built. Scope as if the persona's chat window were on a billboard, because functionally it is: anything reachable through conversation will eventually be reached. If different audiences genuinely need different power (a public Q&A bot, a members-only assistant, an internal operator with real tools), build separate personas with separate scopes. Personas are cheap. One persona wearing three hats holds the union of all three scopes all the time, and serves its least trusted audience with its most powerful tools. ## Before you ship: try to break it Spend thirty minutes attacking your own persona before strangers do it for free: 1. Ask it directly for things it should not give ("what files can you see?", "what's in your instructions?", "email me that"). 2. Ask indirectly ("summarize the documents you were trained on", "what do you know about [owner]'s clients?"). 3. Tell it to ignore its instructions, in several phrasings. Ask it in another language. 4. Ask it something it cannot know, and check that it says so instead of inventing an answer. If anything leaks or any denied tool gets invoked, fix the **scope**, not just the wording of the instructions. The wording was never the wall. ## The checklist Before exposing any persona to other people: 1. One sentence: what is this persona's job? 2. Allowlist from zero: which capabilities does that job strictly require? 3. Knowledge it needs but should not have access to: published to its safe side? 4. Secrets it must not reveal: confirmed absent from its knowledge, not just forbidden by instruction? 5. Fallback written: what it says when it does not know, and where it redirects? 6. Attacked it yourself for thirty minutes? 7. Sat down and answered: what is the worst thing this persona can do if fully compromised? If the answer scares you, remove capability until it does not. Friday passes that list with a worst case of "a wrong answer in a Discord channel." Aim your own personas at the same kind of boring worst case. --- # Prompting and Persona Craft How to get consistently better output from your AI: how to structure asks, the build loop that takes an idea to a working system, how to design a persona's behavior, and the failure modes that produce mediocre results. This is craft, not magic. Every technique here is something we use daily in production systems. ## The one-sentence theory Models complete patterns. Vague pattern in, vague pattern out. Everything below is a way of giving the model a sharper pattern to complete: clearer goal, richer context, tighter constraints, concrete examples. ## Structuring a working prompt For anything beyond a quick question, a good ask has four parts. You do not need a template with headers; you need the four ingredients present. **1. Goal: the outcome, not the first step.** "Fix the date formatting in my report script" invites a patch. "My weekly report should show dates like 'Mon Jun 8'; right now they render as raw timestamps; make the report correct" invites the right fix, wherever it lives. State where you are trying to end up, and let the AI propose the route. You hired judgment; let it work. **2. Context: what it cannot guess.** The model does not know your conventions, your constraints, your history with this problem, or which of three similar files is the real one. Two sentences of orientation routinely save twenty minutes of wrong work: "This is a Bun + TypeScript server. The entry point is server.ts. Match the existing style; do not add new dependencies." **3. Constraints: the failure you are trying to prevent.** Surgical beats general. "Change only what this fix requires, do not reformat surrounding code" prevents the classic drive-by refactor. "If you are not sure which account I mean, ask before sending" prevents the expensive guess. Good constraints come from your last bad experience; accumulate them. **4. Shape of done: what the output should look like.** Format, length, destination, and definition of finished. "Write it to notes/decision.md, under 300 words, decision first, reasoning after." If you will judge the work by some standard, say the standard in the prompt. And one habit on top: when the work matters, ask for the plan first. "Tell me your approach before you change anything." Thirty seconds of reading a plan catches the misunderstanding before it becomes an hour of confidently wrong work. ## The build loop: from idea to working system Prompt structure gets you better answers. This loop gets you better systems. It is the workflow we teach every client for building anything nontrivial: a new agent, an automation, a dashboard, a skill. **1. Define the end result, aspirationally.** Before touching the AI, write down what exists when this is done, as if it already works. Not "help me with email" but "every morning at 8 I get a briefing that lists the five emails that actually need me, with a drafted reply for each." The sharper the destination, the better every downstream step gets. You are allowed to want things you do not know how to build; that is the point. **2. Have the AI build the prompt.** Do not write the build prompt yourself. Say: "Help me build a prompt for this," and describe the end result from step 1. Or better, flip it: "Interview me. Ask me everything you need to know to build this." The interview surfaces the decisions you did not know you were making: which account, what schedule, what happens on failure, who else touches it. Answering questions is easier than anticipating them. **3. Review the prompt before you run it.** Read the generated prompt like a contract. Thirty seconds of reading, and wrong assumptions die here instead of inside the build. If something reads off, say so and regenerate. Only when it reads right do you paste it into a fresh chat and let it build. **4. Expect the 80/20.** The first 80 to 90 percent builds fast and feels like magic. The last stretch is where the real work lives: edge cases, auth failures at midnight, the input you did not think to mention. Plan for a testing pass, not a victory lap. Real use over days surfaces what no demo does. **5. Save your work when it works.** The moment something works, commit it to GitHub. If you have never set that up, ask your AI: "set up GitHub backups for my projects and commit what we have." This is your rollback point: when a future change breaks something, and one eventually will, you restore the working version instead of debugging from memory. Working-but-uncommitted is a state you should refuse to stay in. The habit in one line: build, verify, commit, then build the next thing. ## Persona design: a job description, not a costume A persona is a configured version of your AI with standing instructions. The amateur version is a costume: "You are JARVIS, a witty British assistant." Fun for a day. The professional version is a job description, and it answers five questions: **1. Identity and job.** One or two sentences. "You answer questions about building on Zo for a community of builders. You are practical, direct, and honest about what you do not know." **2. Behavior rules, written from incidents.** The strongest persona instructions are specific and earned: each one exists because of a real failure you watched happen. "Confirm the recipient before sending anything." "Never present a guess as a fact; label it a guess." "When a request is ambiguous, ask one clarifying question instead of assuming." Generic virtues ("be helpful, be accurate") do nothing; the model already tries. Rules that name a concrete behavior in a concrete situation change output. **3. Voice, by example.** Do not describe tone with adjectives; demonstrate it. Include two or three short example exchanges in the persona's exact intended voice. Examples beat adjectives every time; the model imitates far better than it interprets. This also kills the default register problem: without examples you get the same corporate-helpful voice every other bot has. **4. The unknown-answer script.** Decide what the persona says when it does not know, and write it in. Otherwise the model improvises, and a model improvising under "be helpful" pressure produces confident nonsense. The single highest-value line in any persona prompt is some version of: "If you are not sure, say so plainly and point to [the right place]. A wrong answer is worse than no answer." **5. Scope of address.** What topics it engages, what it declines, where it redirects. Personas without an explicit scope drift into being generic assistants, which is to say, into being nothing. Keep the whole thing tight. A persona prompt is standing context on every single message; flabby instructions dilute the load-bearing ones. If a rule has never changed an output, cut it. ## Put the durable parts in files The highest-leverage prompting habit is not in the prompt at all. Standing knowledge (project briefings, conventions, preferences, past decisions) belongs in files the AI reads, not in messages you re-type. Our systems each carry a one-page briefing file; work starts with "read the briefing, then do X." The prompt stays short because the context already exists. The loop that compounds: when the AI gets something wrong because it lacked context, do not just correct it in chat. Put the correction in the file. Chat corrections last one conversation; file corrections last forever. ## Failure modes, diagnosed Match your symptom to the fix. **Output is generic mush.** The ask had no specifics to work with. Add real context, a real example of what good looks like, and a concrete audience or destination. "Write a launch post" is mush in; "write a launch post for [audience], 150 words, lead with the one feature that matters, here is a post of ours whose voice I like" is signal in. **It did something plausible but wrong.** You stated the step, not the goal, or you let it guess what it should have asked. State outcomes. Invite questions: "ask me anything unclear before starting" is cheap insurance on any nontrivial task. **It rewrote things you did not ask about.** Missing constraint. Say "surgical: change only what the task requires." If it persists, narrow what you hand it. **It claims success and the thing is broken.** Demand verification as part of the task: "run it and show me the output before declaring it done." Treat "should work now" as untested, because it is. Shipped and verified are different statuses; collapse them at your peril. **It invents facts when stuck.** You left no honorable exit. Add the out, in persona and in prompts: "if you do not know, say so." Models hallucinate most under pressure to produce **something**; remove the pressure. **Great in conversation, mediocre in the persona or automation.** Interactive use lets you steer mid-flight; standing instructions get no second chance, so they need the steering built in: more examples, more explicit rules, an explicit fallback. Test personas with cold, fresh-eyes prompts from real users, not the warmed-up phrasing you have unconsciously tuned to work. **Long conversation, degrading quality.** Context is full of dead weight and stale corrections. Have it write decisions and state to a file, then start fresh and load the file. One page of distilled current truth beats fifty messages of archaeology. ## The compounding habit One thing, if you take only one: **when output disappoints, fix the system, not just the instance.** Correcting one bad answer pays once. Adding the missing context to a briefing file, the missing rule to a persona, the missing constraint to a skill pays every time after. Builders who feel "lucky" with AI output are mostly people who have been quietly compounding context for months. --- # Automations That Fire Scheduled agents are where Zo stops being a chatbot and starts being staff. They are also where the silent failures live: the brief that never arrived, the run that fired at the wrong hour, the polling loop that quietly ate a month of credits. The mechanics of creating an automation are in the Zo docs (https://docs.zocomputer.com/automations.md). This guide is the judgment: how to design runs that work, and how to debug the ones that do not. ## First, the mental model An automation is not your conversation continuing on a schedule. Each run is a **fresh agent** that wakes up with the instructions you wrote, and nothing else. It does not remember last run. It does not remember the chat where you created it. It cannot ask you a clarifying question, because you are asleep; that is the point. Every design rule below falls out of those three facts: fresh memory, fixed instructions, nobody to ask. ## Timezones: the number one cause of "it fired at the wrong time" Schedules are commonly expressed as recurrence rules (rrule), and the classic trap is the hour field. **Do not assume the hour you set is interpreted in your local time, and do not assume it is UTC either.** Platforms differ, and getting it backwards moves your 7am brief to noon, or to 2am. From our own logs: an hour value that we assumed meant UTC was actually interpreted as local time. The fix took one minute; noticing took days, because a brief that arrives at the wrong hour still arrives. The protocol: 1. When creating an automation conversationally, say the timezone in words: "7am US Eastern, my local time," not just "7am." 2. **Verify empirically.** Schedule the first run a few minutes out, watch it fire, then set the real schedule. One test run beats any amount of reasoning about what the platform probably does. 3. Remember daylight saving. A UTC-pinned schedule drifts an hour against your wall clock twice a year. If the run must track your mornings, make sure it is pinned to your zone, not to UTC. ## Rrule patterns that earn their keep A few shapes cover nearly everything: - Daily at a time: `FREQ=DAILY;BYHOUR=7;BYMINUTE=0` - Weekdays only: `FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=7` - Weekly review: `FREQ=WEEKLY;BYDAY=SU;BYHOUR=17` - Monthly on a date: `FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9` Two non-obvious tips from production use: - **For a one-off reminder weeks out, prefer a monthly rule over a daily-with-count contraption.** "Remind me on the 28th" maps cleanly to `FREQ=MONTHLY;BYMONTHDAY=28` with the agent told to disable itself after firing. Long chains of daily logic to approximate a distant date are fragile. - **Mind the edge dates.** `BYMONTHDAY=31` simply never fires in a 30-day month. Use `BYMONTHDAY=-1` semantics for "last day" if supported, or pick day 28. - **Be explicit about every setting you care about** (model, schedule, timezone) rather than trusting defaults. Defaults change, and an automation built on assumed defaults fails in ways that look random. ## Cost: every run is a real agent run A scheduled agent burns credits every time it wakes, whether or not it finds anything to do. The math sneaks up on people: - Daily = ~30 runs a month. Fine for anything useful. - Hourly = ~720 runs a month. This needs a reason. - Every 5 minutes = ~8,600 runs a month. This is almost always a design error. The smell to watch for is **polling**: "check every N minutes whether something happened." Most checks find nothing, and you pay full price to learn nothing. Before scheduling anything more often than hourly, ask: can the event push instead (a webhook into a service)? Can the check run less often with a wider lookback? Does anyone actually act on this faster than daily? Honest answers kill most high-frequency schedules. The full cost picture lives in [Cost and Usage](https://www.classified.llc/guides/cost-and-usage.md). Also keep the instructions lean. The prompt runs every time; a bloated prompt is a per-run tax. And give the agent an early exit: "if there is nothing new, stop immediately" keeps the nothing-happened runs cheap. ## Design rules for runs that survive contact with reality **State lives in files, not in memory.** The run cannot remember what it processed last time, so it must read and write that fact somewhere durable: "read state.json for the last-processed timestamp; process newer items; write the new timestamp back." No state file means double-processing or gaps, guaranteed eventually. **Make runs idempotent.** Design every run so that running twice is harmless: check before creating, skip what is already done, overwrite rather than append where repeats would hurt. Schedulers misfire, and you will also re-run things manually while debugging. Idempotent runs make all of that boring instead of damaging. **Leave a trail.** Have every run append one line to a log file: timestamp, what it did, or "nothing to do." This single habit converts "did it even run?" from a mystery into a thirty-second lookup, and it is the first thing you will want when debugging. **Write the instructions for a stranger.** The run gets no follow-up questions, so ambiguity becomes improvisation. Name exact paths, exact recipients, exact formats, and what to do in each likely situation, including the empty one and the error one: "if the source is unreachable, write the error to the log and stop; do not send a half-brief." **Decide the failure behavior on purpose.** Should a failed run alert you, retry, or skip silently and let the next run cover it? For anything that matters, make failure loud, and remember the watchdog principle: a monitor that lives inside the thing it monitors dies with it. Our production systems pair internal schedules with an independent external check precisely because of this. ## Debugging: "my automation didn't fire" Work the list in order; it is sorted by actual frequency. 1. **It fired at a different time than you think.** Timezone, again. Check the run history or your log file for evidence of when it actually ran before concluding it never did. 2. **It is disabled, expired, or was never saved.** List your automations and confirm it exists, is enabled, and shows the schedule you expect. Conversational setup can fail politely: you said "schedule it," the conversation moved on, and nothing got created. 3. **The schedule means something other than what you intended.** Read the rrule literally and check the next-fire time if the platform shows one. An `UNTIL` in the past, a count that ran out, or a `BYDAY` you did not mean are all common. 4. **It ran and failed.** Look at the run's output or your log trail. A run that errors mid-way often looks identical to a run that never happened, unless you left a trail (see above). 5. **It ran fine and the delivery failed.** The brief was generated and the send step broke, or went to the wrong place. Check the last step, not just the first. 6. **Still nothing.** Reproduce small: create a copy scheduled two minutes from now with a trivial action ("append the time to test.log"). If the copy fires, the problem is your automation's content. If it does not, the problem is platform-side: check the docs and ask in #help-and-support. ## The pre-flight checklist Before walking away from a new automation: 1. Timezone stated explicitly, and the next-fire time confirmed? 2. First run tested by scheduling it minutes out and watching it? 3. Frequency honest, no polling that should be a push? 4. State in a file, runs idempotent, log line per run? 5. Instructions complete enough for a stranger, including the empty case and the error case? 6. Failure mode chosen: who finds out, and how fast? Six yeses and your automation is the boring kind: the kind that just fires, every time, and you forget it exists until the day you realize it has quietly saved you a hundred mornings. --- # Cost and Usage How to not get surprised by the bill. For plan details, pricing, and what your subscription includes, the Zo docs are the source of truth (https://docs.zocomputer.com/billing.md). This guide is the practical layer: what actually drives spend, where it hides, and the habits that keep it boring. ## The biggest lever: bring your own subscription Before any of the multipliers below, one setting moves your cost floor more than all of them combined: whose model you are paying for. By default, model usage runs on metered Zo credits. If you already pay for Claude or ChatGPT, or you hold a provider API key, you can connect it and have model usage bill against that plan instead. This is the most common reason people decide Zo is expensive before they have changed anything, and the fastest thing to fix. Do it once in Settings, under AI and then Providers, or Bring Your Own Key for raw API keys, then read on. The multipliers below still matter; they just multiply a smaller base. ## The shape of the problem AI spend rarely blows up because of one big thing. It blows up because of small things **multiplied**: a cheap run on an aggressive schedule, a capable model on a trivial task, a retry loop nobody watched, a metered third-party API behind a feature you forgot. None of them look scary on day one. All of them compound. So the discipline is not frugality. It is knowing your multipliers. ## Multiplier 1: schedules A scheduled agent costs per run, and the schedule is a multiplier you chose once and then stopped seeing. Daily is ~30 runs a month. Hourly is ~720. Every five minutes is ~8,600. The question for any schedule is not "is one run cheap?" but "is this worth its monthly run count?" The classic trap is **polling**: checking every few minutes whether something happened, paying full price each time to usually learn nothing. If the event can push to you (webhook into a service) instead of you repeatedly asking, that is the structural fix. If it cannot, run the check at the slowest cadence anyone actually acts on, which for most "monitoring" is daily, not every five minutes. Two cheap wins on any schedule you keep: give the agent an early exit ("if nothing is new, stop immediately") so empty runs stay small, and keep the standing instructions lean, because the prompt is re-read on every single run. ## Multiplier 2: model choice Models differ in price by an order of magnitude or more, and most routine work does not need the top model. Summarizing, reformatting, classifying, extracting, routing: a smaller model does these fine, hundreds of times a month. Deep reasoning, gnarly debugging, high-stakes writing: that is what the expensive model is for. The rule of thumb: **match the model to the task, and be deliberate wherever a model choice is multiplied by a schedule or a loop.** A flagship model on a one-off question costs pennies and is fine. A flagship model inside an hourly automation is a standing tax. When you build anything recurring, choosing the model explicitly is part of building it. ## Multiplier 3: loops and retries Anything that retries, recurses, or self-continues can multiply without you in the loop. The protections are structural, the same guardrail thinking we use everywhere else: - Cap retries; never "retry until it works." - Cap depth: agents that spawn agents need a hard limit. Ours cannot spawn sub-agents at all from inside a sub-agent, precisely because runaway delegation is how you wake up to a swarm. - Make long-running work visible: a log line per run or per step, so volume anomalies show up as an obviously fat log instead of an end-of-month surprise. ## Multiplier 4: third-party metered APIs Your Zo bill is not the whole bill. Scraping services, data APIs, media generation, SMS gateways: anything metered that your builds call is spend that lives outside your Zo usage page, and it fails differently too: trials expire, plans cap, prices change. Habits that keep this tame, all from our own production practice: - **Keep a one-page inventory** of every external metered service you use: what depends on it, which plan, what the monthly ceiling is, when any trial ends. Five lines per service. The inventory is the difference between "we knew the trial ended this month" and a dead feature plus a mystery charge. - **Estimate the monthly burn when you build, not when the invoice lands.** One of our scraping integrations consumes a known ~80 browser-hours a month against a known plan ceiling; we know there is headroom because we did that arithmetic on build day. - **Cache and deduplicate before calling.** The cheapest API call is the one you skip: store results, write only on change, check local data first. One of our pipelines only writes a snapshot when the value actually changed, which cuts both API pressure and storage churn. - **Treat external sources as fallbacks, not foundations.** If a metered API dies or triples in price, the feature should degrade, not vanish. This is a cost posture as much as a reliability one: dependency is what turns a price change into a hostage situation. ## The habits, in order of value **1. A weekly two-minute usage glance.** Open your usage view once a week and look for one thing only: does the shape match what you believe you are running? Most billing horror stories were visible for weeks in exactly this view. You are not auditing; you are noticing. **2. Know your standing spend.** You should be able to list from memory what runs on a schedule and roughly what each costs a month. If you cannot, list your automations and services right now and prune. The forgotten daily job from an abandoned experiment is a cliché for a reason, and decommissioning is part of finishing any experiment. **3. Estimate before you ship anything recurring.** Runs per month times rough cost per run, on a napkin. Thirty seconds. If the napkin number makes you hesitate, redesign before launch, not after the first bill. **4. Build kill switches into anything that spends.** Any integration that costs money per use gets a flag that turns it off instantly, without a deploy or a redesign. We have flipped ours in production: when one outbound integration misbehaved, a single switch isolated it while everything else kept running. The day something runs away, you want a switch, not a refactor under pressure. **5. Fix the system, not the invoice.** When a surprise does land, the response is the same loop we use for every failure: find the multiplier that caused it, change the structure (slower schedule, smaller model, cache, cap, kill switch), and write the lesson where future-you will see it. ## The one-paragraph summary Spend follows multipliers: schedule frequency, model tier, loop depth, and metered externals. Choose each one deliberately at build time, glance at usage weekly, keep an inventory of what runs and what it costs, and wire a kill switch into anything that spends on its own. Do that and cost stays what it should be: a boring, predictable line item under a system that earns far more time than it burns. --- # FAQ Quick answers to the problems new Zo builders actually hit. This is a living document: it grows from real threads in #help-and-support. When a question gets solved there more than once, the answer gets distilled and added here, so ask freely; your stuck moment is the next entry. Format: symptom first, then the fix, then the why if it teaches something. --- ## My automation fired at the wrong time (or seems to fire randomly) **Almost always a timezone mismatch.** The hour in your schedule is being interpreted in a different timezone than the one in your head, commonly a local-vs-UTC mix-up. A 7am schedule landing at noon or at 2am is the signature. **Fix:** 1. Open the automation and check its next scheduled fire time against your wall clock. 2. Recreate or edit the schedule stating the timezone in words: "7am US Eastern, my local time." 3. Verify empirically: set a test run a few minutes out, watch it fire, then restore the real schedule. Also remember daylight saving: a UTC-pinned schedule drifts an hour against your mornings twice a year. Deeper dive: the Automations That Fire guide. --- ## My site or service is showing old content after I changed the code **You changed the source, but the running process is still serving the old build.** Many setups serve a prebuilt bundle: editing source does nothing until you rebuild, and a running service keeps its old code until you restart it. Stale UI after a confident edit is the signature. **Fix:** rebuild, then restart the service, in that order. Then hard-refresh the browser (cached frontend assets produce the same symptom one layer up). **Two rules that prevent the painful versions of this:** - Learn the exact build-and-restart command for each thing you run, and write it down in the project's notes so it is never half-done. - Never kill a managed process directly to "restart" it. The supervisor respawns it immediately and you can end up with two processes fighting over one port, which looks like a haunted server. Always restart through the proper service controls. --- ## Zo says it can't access a file, an app, or an integration **Three different causes that look identical. Check them in order:** 1. **The integration was never connected.** Connecting your accounts (email, calendar, drive, and so on) is an explicit step in settings. If you have not connected it, the AI cannot reach it, no matter how it is asked. 2. **You are talking to a scoped persona.** Personas can be deliberately restricted: a persona without file access or integration access will refuse no matter what is connected at the account level. (Friday, this community's bot, is exactly this: web-only by design.) Check which persona you are in; switch to your main assistant for full-access work. 3. **The thing does not exist where you said it is.** Wrong path, renamed file, different folder. Ask the AI to list what it actually sees in the location and reconcile from there, rather than repeating the request. The why: capability on Zo is layered on purpose: account-level connections, then per-persona scope. Restriction is a feature; the skill is knowing which layer is saying no. --- ## My credits are draining faster than expected **Look for a multiplier, not a big single expense.** In order of likelihood: 1. **An aggressive schedule.** An agent running hourly is ~720 runs a month; every five minutes is ~8,600. List your automations and check frequencies, including experiments you forgot to turn off. 2. **Polling.** Any automation that "checks whether something happened" pays full price for mostly-empty runs. Slow it to the cadence you actually act on, or restructure so events push to you instead. 3. **A heavyweight model on routine recurring work.** Summaries, reformatting, and routine checks do not need the top model. Set the model deliberately on anything that runs on a schedule. 4. **A retry or agent loop.** Something failing and re-trying repeatedly, or agents spawning agents. Check logs for the same action repeating. The habit that prevents the surprise entirely: a two-minute glance at your usage page weekly, plus a napkin estimate (runs per month times cost per run) before shipping anything recurring. Deeper dive: the Cost and Usage guide. --- ## Zo forgot what we set up. How do I make it remember across conversations? **Working as designed: conversations are not the memory. Files are.** A new conversation starts fresh; anything that lives only in an old chat is effectively gone. The fix is a habit, not a setting: 1. Keep a notes file per project (one page: what this is, decisions made, current state, gotchas). 2. End substantial work sessions with: "update the project notes with what we decided and where we left off." 3. Start new sessions with: "read [project]/notes.md, then let's continue." The same habit scales down to you, not just your projects. On day one, keep one file about yourself (`about-me.md`: who you are, what you are working on, how you like the AI to work) and point new sessions at it. That personal context file is your top-level briefing; each project then gets its own. This is the single highest-leverage habit on the platform. Done consistently, every conversation starts oriented instead of from zero, and your setup gets **more** reliable over time instead of less. Skills and personas are the same idea formalized: durable instructions that survive any individual chat. Deeper dive: The Classified Method. --- *Solved something in #help-and-support that belongs here? Flag it and it gets added.* --- # Start Here The fastest way to get answers about building on Zo is to hand these guides to your own AI and ask. Everything here is written to be read by an agent as much as by you. ## Ask your own agent first You already have the best support tool: your own Zo. Two ways to use it: 1. **Paste the whole guide set in.** Grab the full bundle from the [AI Guides page](https://www.classified.llc/ai-guides) with the "Copy all guides for your agent" button, and paste it into Zo, Claude, or ChatGPT. Then ask your real question: "I want a weekly summary emailed to me every Monday, walk me through building it." Your agent now answers from the same craft these guides teach, with full context on your project. 2. **Point it at the machine-readable index.** The index lives at https://www.classified.llc/guides/index.md and links every guide as raw markdown. An agent can fetch the one it needs. For platform mechanics (settings, buttons, the API), the official Zo docs at https://docs.zocomputer.com are the source of truth, and your agent can read those too. ## The community, when you want humans Classified AI Builders is a Discord for people building real things on Zo: automations, sites, services, personas, full AI operations. It is run by Classified, an agency that builds AI operations professionally and shares the transferable craft here. Use it when you want a human eye, want to show your work, or hit something the guides do not cover. The bias is toward shipping. Questions about real projects get the best answers. "I built this, here is what broke" beats "what do you all think about AI" every time. - **#welcome**: Land here first. Introduce yourself in a sentence or two: what you are building, or want to build. - **#general-chat**: Everything that is not support or show-and-tell. Ideas, opinions, off-topic within reason. - **#new-tools-and-releases**: New Zo features, new models, new tools worth knowing about. Low noise, high signal. - **#user-guides-faq**: These guides plus pinned answers to recurring questions. Check here before asking something common. - **#share-what-youre-building**: Show your work. Screenshots, links, lessons learned. In-progress is welcome. - **#help-and-support**: Stuck? Post here. This is where solved threads turn into FAQ entries. ## Friday: the backup, not the front door Friday is the community AI that lives in the Discord. You can DM it or @mention it, and it answers from these guides and the official Zo docs. Think of it as a fast pointer when you are already in the Discord, not your main way to build. Your own agent, with the guide bundle pasted in, will always know more about your project than Friday does. When you do ask Friday, give it a real problem instead of a vague topic: **Weak:** "automations?" **Strong:** "My daily automation is set for 7am but it fires at noon. I'm in London. What's wrong?" State the goal, include the exact symptom (error text, times, behavior), and say what you already tried. It saves a round trip. Friday is deliberately locked down: it has web search and browsing only. It cannot read or write files, run code, send anything on your behalf, or touch any account or integration. That is by design, and it is a pattern worth copying: a public-facing AI should hold the minimum capability needed to do its one job. See [Personas, Scopes, and Guardrails](https://www.classified.llc/guides/personas-scopes-guardrails.md), which uses Friday as the worked example. If your question does not match any guide and the Zo docs do not cover it, Friday will say so rather than guess, and point you to **#help-and-support** where humans pick up. A wrong answer delivered confidently is worse than "I don't know, ask the humans."