Use cases
Agents do the repeatable work. You keep the goals, the brand, and the spend. We run it on ourselves first, so the three cases below are from our own work. (This isn't a chatbot.)
Three cases from our own work
Each case is our own project. Every number names its source.
This site, built by Presence
Situation: Our old website ran on Squarespace. Agents draft fast, and left alone they invent facts.
What agents did: They draft the pages and posts in markdown from the brand kit. Presence builds the whole site from the approved files.
What a person decided: The Board approved replacing the Squarespace website with this static site.
Outcome: Live on Cloudflare Pages since October 3, 2026 (source: README.md at commit a973df8).
Read: Human-in-the-loop publishing · Brand kits as source of truth
A visual refresh, shipped on proof
Situation: Visual changes are easy to call done and hard to check.
What agents did: They worked through seven issues, MEL-1904 to MEL-1910 (source: docs/proofs at commit a973df8), and attached a screenshot for every acceptance criterion.
What a person decided: Each issue starts only after the one before it passes, and nothing publishes, changes DNS, or spends money.
Outcome: 21 of 21 acceptance criteria pass, each with screenshot proof (source: docs/proofs at commit a973df8).
Read: How we check agent work
Dark mode that stays readable
Situation: A dark theme can quietly break contrast on some pages, links, and focus rings.
What agents did: They built the theme system, wrote 37 theme test cases, and checked contrast on 32 pages, in both themes, at 2 widths (source: PR #12).
What a person decided: A person picked this theme system over an alternative build and asked for one more mobile fix before it merged.
Outcome: The contrast sweep found 0 failures, and 1,386 of 1,388 tests passed in that run (source: PR #12).
Read: Brand kits as source of truth
What we set up with you
1. Who owns what
You own the goals and the spend. Each specialist agent owns one scoped job. You get clean handoffs, recovery when something breaks, one job at a time, and a Board override. You can review all of it. Nothing publishes on its own.
2. Where the models run
We work out with you where each model runs. You read the draft before a customer does.
3. Which model is allowed
Match the task to privacy, latency, and budget. One model for every task is not a plan.
4. What they're allowed to say
They look up the brand kit, runbooks, tickets, and approved pages. They cite. A filter blocks claims we forbid. They stop inventing the company.
5. Whether the work got better
Changes run against gated tests and a checklist before a person signs off, so you can see whether the work got better. A demo that sounds fluent doesn't count.
Presence, as a working example
- Brand and content CRM: your identity in a form agents can read. They read it and never make it up.
- Static site generator: approved pages become a branded site
- Social adapters: X and LinkedIn posts wait in dry-run queues
Details: Product.
How the work usually flows
We learn how the work should go. Then we set who does which job, which model answers, and which facts it can cite. Agents draft. People and the Board approve. The CRM tracks where each piece stands. You preview the site. Social stays in dry-run. When you're ready, you turn on one channel.