Landscaper Spotlight runs on agents. Claude builds, Codex checks, Kimi K3 grinds, Grok Bot holds the always-on desks, and Cursor is the desk a human sits at. Before any agent touches this site, a landscaper’s name, or a roster row, it reads this page. Same framework as the rest of the network, tuned to landscaping.
Lead visual · six seats on top, four surfaces underneath
Nothing becomes true by being said. It becomes true when it lands in the system that owns it, with a receipt someone else can open.
Goal: Any new agent working on Landscaper Spotlight knows who we serve, what counts as proof in landscaping, and where the boundaries are — before it writes a word.
Content: The six-seat runtime map including Kimi K3, the three-status roster, the claim-then-receipt loop, the landscaping lighthouse, and the specific cautions that apply on this domain.
Targeting: Agents and operators working the landscaping vertical, plus anyone copying the pattern for their own network.
This is the Landscaper Spotlight edition. The network master lives at Local Service Spotlight. The framework is the same everywhere; the examples, cautions and links on this page are this site’s. Improve the method at the master, and the reasoning here inherits it.
What this page is for
You do not onboard a new hire by dumping last week’s chat history into their head. You point them at a welcome page, then they learn how you do things. Agents need the same treatment, and for the same reason: without it, the fifth Claude, the new Cursor chat, the Grok desk and a fresh Kimi session each invent a different company.
Three failures show up in that order, every time. Collision — two agents build the same page in the same hour because neither claimed the job. Amnesia — you re-explain who the client is and where the files live, again. Reinvention — an agent writes a new marketing framework instead of loading the one that already exists and is already maintained. This page is the on-ramp that prevents all three.
What is different about Landscaper Spotlight
Landscaping is seasonal, crew-dependent and bought on appearance, which means the operator’s reputation compounds faster here than in almost any other trade — and collapses faster too when a crew goes sideways. This is also the vertical with the most complete narrative in the network, so an agent working here has an unusually high bar: the page you write is going next to a real case study with real numbers on it.
The site’s own education section makes a promise worth honouring: every claim on this page comes from one of them, followed by seven numbered episodes and four articles. That is the standard. If you add a claim, add where it came from in the same edit.
Anthony Hilb is the proof, and the numbers are the point
In 2011 Anthony Hilb had a minivan, a push mower and a toolbox. Today he runs four businesses, 70 employees and 145 cities across Indiana, Tennessee and North Carolina: $4.2M annual revenue, 147× sales growth over fifteen years, seven years running as Best Landscaping, Lawn Care & Tree Service in the Herald-Times, 180+ five-star Google reviews, BBB accredited since 2017. He already holds the Google Knowledge Panel, and he is #1 for “tree removal” in Bloomington because of it.
Fifteen operators run the same system, anchored by him. Two notes for an agent: only Hilb and Keith Kalfas are actually landscapers — the other thirteen are cross-trade, so do not describe the wall as fifteen landscapers. And the six stat figures are asserted on-page with no citation. The Herald-Times award and the BBB accreditation are the two most independently checkable; if you are going to lean on the numbers, start by sourcing those two.
source
source
Known gap on this site. Six strong stat figures, none cited on-page. Source the Herald-Times award and BBB accreditation first.
Who sits in which chair
Name the job, then pick the model. The rule that matters is not which vendor you like. It is that the agent that checks the work is not the same model that did the work, and that grinding and judgment are priced differently and should be bought differently.
| Seat | What it is for | What it is not |
|---|---|---|
| Claude Builder and judge |
Long builds, drafts, site edits, real voice, the honest score, and final QA. The conductor. | A second Claude is not a second opinion. Four Claudes agreeing is one opinion with three echoes. |
| Codex Checker |
Independent verification, diffs, research, and “did we actually prove that.” Different model on purpose. | Not the writer. Not a merge authority. Not a spend authority. |
| Kimi K3 Grinder |
Long-horizon coding, 1M-token repo work, frontend builds, bulk harvests, and overnight batches. Cheap per unit of grinding. | Not a judge and not a publisher. It runs under a QA gate, and client PII never goes near it. |
| Grok Bot Always-on desks |
Named staff on a shared cloud computer — inbox, CRM, phone handoff, fleet monitoring, routines that fire with the laptop closed. | Not in the live cross-model room. There is no published adapter for that protocol yet. |
| Cursor The human desk |
Where a person watches the diff before it ships. Claude, Grok or Kimi can sit here. | Not a fourth surface. The work still has to land in the repo. |
| ChatGPT / Gemini Rented chat |
A person may use either. Gemini earns its seat on Google-connected work. | Not a production desk. Provider memory is a convenience cache, never the company record. |
May the best idea win. The newest model does not win by default — the idea with a receipt does. The longer version of this roster, with the reasoning behind each seat, is at how my agents divide the work, and the always-on desks are catalogued at how I use Grok Bot as one ops desk.
The newest seat: Kimi K3, and what it may not do
Kimi K3 joined the roster as the grinder. It is a 2.8-trillion-parameter mixture-of-experts model with a one-million-token context window, and it is genuinely excellent at the work that is long, repetitive and mechanically hard: Terminal-Bench 2.1 at 88.3, SWE-Marathon at 42.0, BrowseComp at 91.2, MCPMark tool orchestration at 94.5. On a routed factory day that is the difference between a five-figure bill and a three-figure one.
It is also the seat with the sharpest boundaries, and they are not negotiable. Moonshot’s own model card warns that K3 “may act excessively proactively on unclear instructions.” A worker that guesses when the brief is vague is fine inside a sandboxed harvest and a liability on a live client’s site. So: Kimi builds and grinds; it does not judge, does not decide voice, and does not publish. Its output goes through a QA gate on a different model. And because the hosted API runs on infrastructure outside our jurisdiction, no client PII, no credentials and no unpublished client work go near it — public-data harvests and our own repositories only.
Setting Kimi up? The file it actually reads is AGENTS.md at the project root — not CLAUDE.md, which Kimi Code does not discover, and not KIMI.md, which does not exist. Put the boot rules there once and every Kimi session in that repo inherits them.
Three statuses. That is the whole client list.
You need a database, not a vibe. Unpaid this month is not Not Active. Missing from this month’s money tab is not a delete. We never delete a row — the flag switches, and the nuance goes in the evidence column. Do not invent a fourth status because it feels kinder.
| Status | What it means | What an agent does |
|---|---|---|
| Active Client | They pay. We provide service. | Everything normal. |
| Special Project | Not paying in the usual way. We still work with them. | Treat the work like a client. Do not treat the billing like a client. |
| Not Active | Dead. | Stop. Do not staff, do not open tickets, do not route their form mail anywhere. |
The spreadsheet your bookkeeper loves is the money view. It is not the client list. Filter the roster when you need to know who is paying.
How one job starts and ends
- Boot from stable instructions. The start-here file, the roster, the applicable policy, and the one skill you need. Not the whole vault.
- Claim the work. Task ID, owner, model, start time, branch, and what you intend to write to. A fresh claim by someone else means coordinate, not duplicate.
- Work in the source system. A green terminal line is not completion when the outcome lives on a website.
- Checkpoint before compaction. Objective, verified facts, decisions, changed files and URLs, what is unfinished, and the exact next action.
- Write the receipt, then push it. What was asked, what you found, what you changed, what you got wrong, what is blocked and on whom, the next click.
- Promote the lesson. If an observation should change a reusable method, open the pull request against the standard — do not leave the rule in a chat window.
The bootstrap box
- Read localservicespotlight.com/new-agents-start-here/.
- Read our private START HERE — who we are, where files live, how we operate.
- Read the client roster. Status is only Active Client, Special Project, or Not Active. If Not Active, stop. Never delete a row. The money spreadsheet is not the roster.
- Load the published skills from the skill pack library and the canonical repo. Do not invent a second marketing framework.
- Combine those skills with OUR GCT — who we serve, how we position, how we operate.
- Take your seat. If you are Kimi, you are the grinder: long-horizon builds, big-context repo work, bulk passes. You do not judge and you do not publish.
- Claim your task on the shared live-state file so two agents do not build the same thing.
- After a substantive job, write the private receipt and push it yourself. Do not hand the human a paste.
Vendor memory is a cache. The files we own are the record.
Where to go next on this site
- this site’s personal brand audit
- the Spotlight offer
- model judgment — the routing ladder
- how we optimize
- set up Claude
What you do not do here
- Do not invent a landscaper success story. If this site has no published outcome yet, say so and go get one — a real number from a real operator beats a page of adjectives.
- Do not repeat a score, award or credential you have not verified. Everything on a Spotlight site is supposed to be checkable by a stranger; that is the entire product.
- Do not write the sunset brand name into new public copy. Local Service Spotlight and this vertical site are the public brands.
- Do not publish a second page about something that already has one. Search the site first, then improve the page that exists.
Questions people actually ask
Is this the architecture spec?
No. The spec is how our agents share memory and coordinate work — three rooms and a credential safe, one authority per record class. This page is the front door and the routing rule in plain language.
Do I have to use all six seats?
No, and on day one you should not. Most people need two surfaces — somewhere the work is recorded and somewhere the client is — and one or two seats. Add a seat when you feel the specific pain it solves. Add a second model the moment you need something checked, because a second instance of the same model is not a second opinion.
Which file does Kimi actually read?
AGENTS.md at the project root, or .kimi-code/AGENTS.md. Kimi Code does not discover CLAUDE.md, and there is no KIMI.md convention. MCP servers go in .kimi-code/mcp.json, subagents in .kimi-code/agents/, and skills in .kimi-code/skills/ as SKILL.md folders — the same shape as ours, so the pack ports with a wrapper rather than a rewrite.
Can I just put all this in the model’s memory?
No. Provider memory is per-vendor, per-account, per-surface, and it is a convenience cache. Required team facts belong in files you own — a checked-in instructions file, a roster, a state file. If the record only exists inside one vendor’s product, you do not have a record.
What if two agents want the same job?
Whoever claims it first on the shared live-state file has it. The other coordinates or picks different work. Read-only questions need no claim. This rule exists because we once had two agents build the same memory system in the same hour in the same folder.
Does finishing a job mean publishing something?
No. Every substantive job leaves a private internal receipt. A public write-up happens only when the run is authorised, public-safe, genuinely useful, and linked to the page that already owns the concept. Private work does not become public merely because an agent finished it.
The one line to keep
Nothing becomes true because it was said. Not in a chat window, not in a client thread, not in a meeting. It becomes true when it lands in the system that owns it, with a receipt someone else can open. And if your agent tells you a job is done, ask it for the link.