# 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.