How LLMs Run a Business

A model with no system prompt is a brilliant new hire on day one with no training. It knows English, it can write — but it doesn't know your prices, your tone, your cancellation policy, or which language to reply in. Every customer gets a slightly different answer.

The fix is the startup prompt: one document the agent loads before any conversation and silently re-sends with every turn. It bakes in:

• Identity — "You are Khun Mali, host at Krueng Guesthouse."
• Knowledge — prices, hours, addresses, policies, FAQ.
• Tone — warm, brief, never pushy.
• Language rule — always reply in the guest's language.
• Boundaries — what to refuse, what to escalate to a human.

Toggle the switch below to feel the difference:

Where does this file live?

In a folder next to your agent — typically system_prompts/main.md. The agent reads it on startup, holds it in memory, and prepends it to every model call. Changing the file and restarting the agent is how you "retrain" it — no machine learning required. See section 8 for the full folder layout.

A system prompt sets who the agent is. Workflows define what it does. A workflow is a named sequence of steps the agent follows when a specific kind of request comes in. You write each workflow as its own short markdown file the agent can look up.

Click a workflow below to see the steps:

How the agent picks a workflow

The system prompt usually contains a small router: "If the guest asks about availability or price → use workflows/booking.md. If they ask for food or sights → workflows/recommend.md." The model reads the right file and follows it. Adding a new workflow is just a new markdown file plus one new line in the router.

By itself, an LLM only outputs text. It can't read your calendar, send a LINE message, look up the weather, or charge a credit card. Tools (also called functions or APIs) fix this. You describe a function in JSON; the model decides when to call it; your code runs the function and sends the result back; the model uses the result to write its reply.

This is the agent loop:

What this unlocks

Three guesthouse tools and a system prompt are enough to handle 80% of incoming messages: check the calendar, hold a room, send the booking confirmation on LINE. Add get_weather, currency_convert, find_taxi and you've covered most of the rest. Tools turn a chatbot into an employee.

Everything we've covered — system prompts, workflows, tools — lives as files on disk. The shape of those files is itself instruction. An AI scans your folder before it scans your contents; a clear tree tells it what you have before it has read a single line.

Why naming is documentation

A file called cs_FINAL_v3_REAL_2.md tells a future reader (human or AI) absolutely nothing about what's inside. A file called workflows/booking.md says it all in two words: it lives under workflows, and it handles bookings. The model can guess what's inside without opening it — and more importantly, it can guess where to look when a new request comes in.

Think like REST

The cleanest mental model I know for naming AI files is to borrow from REST URLs. Good REST paths read top-down, general to specific: /customers/123/orders/456. Same idea for your folders:

• Plural for collections, singular for instances. workflows/ holds many; workflows/booking.md is one.
• Nouns, not verbs. prompts/greeting.md, not do_greeting.md. The verb is what the agent does with the file.
• Predictable hierarchy. If prompts/sales/objection_handling.md exists, the AI can guess that prompts/sales/closing.md probably does too. Symmetry is a discoverability tool.
• Lowercase, underscores or hyphens, no spaces. URL-safe and shell-safe. shipping_policy.md works everywhere; Shipping Policy (final).md breaks half your tooling.
• The path is the documentation. Reading tools/payments/refund.json tells you the file is a tool definition, lives in the payments domain, and handles refunds. You haven't opened it yet, but you already know what's inside.

How files evolve

Don't pre-build the perfect tree. Start with one file. Split when it stops fitting in your head.

How an agent uses this tree

On startup, the agent reads system_prompts/main.md. That file ends with a small map: "For bookings, read workflows/booking.md. For menu questions, read data/menu/. For refunds, use tools/payments/refund.json." When a customer message arrives, the agent matches it to a row in that map and reads the linked file before responding. The folder structure isn't decoration — it's the program's table of contents.

Add a CHANGELOG.md at the root. When you change a workflow, add a one-line entry. The agent (and you, six months from now) will thank you.

An agent that only replies when a human messages it is half a business. The other half runs without anyone watching — daily reports, weekly summaries, scheduled price checks, overnight inventory pulls. Same model, same tools, same workflows — but kicked off by a clock instead of a chat message.

Think of it as a factory assembly line. Triggers are the bells that start a shift. The router is the foreman who hands incoming work to the right station. Each workflow is a sequence of stations. The tool shelf sits underneath, available to every station. Outputs come off the end of the line — a LINE message, an email, a database row.

The two trigger types

• Event triggers — fire when something happens. New chat message, payment received, webhook from booking.com.
• Time triggers — fire on the clock. Cron-style schedules: every 5 minutes, every morning at 7, every Friday at 5 PM, the 1st of every month.

You write each schedule as a tiny config file. The agent's startup loads them all and registers each one with a timer. From that point on, the agent runs itself.

Schedules live as plain JSON in schedules/. The agent reads them on startup, registers a timer for each, and from then on calls the named workflow at the configured times. Adding a new schedule = drop in one file, restart the agent.

Once schedules are in place, the agent stops being a chatbot and starts being infrastructure. The owner can take Sunday off — the agent still answers booking inquiries, still files the morning brief, still flags the weekly anomaly. The hardest part is no longer "can the AI write a reply?" — it's "do I trust the AI to fire 100 times a day without supervision?" The answer comes from logs, scenario tests, and the discipline of the file structure we covered in section 8. Clean folders, named workflows, deterministic schedules — together they make autonomy boring, which is exactly what you want.