Zheat Logo
    RadjivRadjivSenior Software Engineer

    Perpetual application: Grok Bot hits Composer agents, Rocky and No More Slop keep the gates

    A perpetual application is a live product that keeps itself in production after launch. Pluggable gates (Appzi, Clarity, Ahrefs). Grok Bot organizes. Cursor Composer builds the local agents. Rocky and No More Slop keep the work fast and clean.

    Follow on LinkedIn

    A perpetual application is a live product that keeps itself in production after launch. It watches real signals, ships fixes, and waits for humans before it invents features. It is not a bot that writes code all night and calls that a roadmap.

    This paper is the map. Field notes for one live case (Order of Battle) are in Why I gave Grok Bot a Routine bot. The two tools that make the loop hold under load are Rocky and No More Slop.

    Canonical URL: https://www.zheat.xyz/en/insights/perpetual-application/


    Table of contents

    1. What is a perpetual application?
    2. Which gates can you add?
    3. Does Grok Bot write the code?
    4. What does Cursor Composer do?
    5. How does Rocky manage the gates?
    6. How does No More Slop review the code?
    7. Why are Rocky and No More Slop the performance?
    8. How does the loop work?
    9. FAQ
    10. Related

    What is a perpetual application?

    A perpetual application is a live product organized so agents keep it healthy after launch: real-user and production signals in, fixes out, features on hold until a human asks.

    A demo that ships once is a project. A product that still gets dead links, crashes, and confused users three months later is the real job.

    A perpetual application is organized so that:

    • Fixes can run on a schedule. Clarity, Sentry, crawl errors, broken UX.
    • Features wait for a human voice. Empty feedback is not a backlog.
    • You own the code. Agents work in your repo, through your gates, on your infra.

    A perpetual app that ships ghost features is just busy. The hold is the product rule, not a lack of agents.


    Which gates can you add?

    Gates are the signals you plug into the loop. You add them per product. You do not need all of them on day one.

    GateWhat it tells the loopTypical owner in the Grok Bot team
    AppziWhat users actually said: bugs, friction, wishesPO reads it. Features stay on hold until there is volume.
    ClarityWhere people rage-click, bounce, hit dead UIRoutine keeps the daily review honest. Developer gets the clip, not a rumor.
    AhrefsWhat search and crawl see after you shipPO looks when findability matters (sitemap, 3XX, dead URLs).
    Sentry (when it is in the stack)Crashes and stack tracesSame daily loop as Clarity.

    You can add more later (Vercel, GitHub, a second feedback tool). The architecture does not change. A new gate is a new input. It is not a new coding agent.

    PO distributes. Routine checks that the schedule still runs. Neither of them patches the repo.


    Does Grok Bot write the code?

    No. Grok Bot does not write the code. If you run a Grok Bot team, treat it as the outer org chart, not the IDE.

    On Order of Battle the public roles are small on purpose:

    RoleJobDoes not do
    RoutineMake sure scheduled work actually fires (Clarity / Sentry / the daily loop)Product decisions. Feature scope. Writing the patch.
    PORead Appzi. Look at Ahrefs when discovery matters. Distribute workShip code.
    Developer (Grok Bot)Turn a ticket into a hit: wake the local agent with a briefInvent the roadmap. Be the editor that types the diff.

    Grok Bot hits the agent. The agent that writes, tests, and opens the PR is a local agent. With this team, that local agent is Cursor. The Grok Bot Developer is the dispatcher. Cursor is where the hands are.


    What does Cursor Composer do?

    Cursor Composer is how we create those local agents.

    You define the worker in Composer: what repo it is in, what it is allowed to touch, which MCP it must use. That agent lives in Cursor (the other app). You then match it to a Grok Bot role.

    • Grok Bot PO / Routine / Developer: organize, schedule, hit.
    • Composer agent: execute in the repo.

    The hit is a brief. Repro steps. A Clarity clip or a Sentry stack when it exists. Coverage first. Then the Composer agent works inside Rocky, not as a free-form chat that pastes the whole tree into context.

    That is the match: Grok Bot team on one side, Composer-made Cursor agents on the other. Same product. Two apps. One loop.


    How does Rocky manage the gates?

    Rocky is the MCP layer on the local agent. It does not replace Composer. It is how the Composer agent stays inside a senior workflow:

    • Graphify-first discovery instead of 20 file reads
    • Handbook (agents, skills, rules) instead of a new prompt every night
    • One devkit gateway instead of a pile of raw tool schemas
    • A pre-PR gate with a clear ready / not_ready

    When the Grok Bot Developer hits the local agent, Rocky is what stops that hit from becoming sloppy agent code on main.

    Rocky is also where extra engineering gates live: lint, scoped tests, architecture check. No More Slop escalates into Rocky when the leftover work is not a style rewrite. See the No More Slop Rocky handoff.

    On a measured React monorepo task, Rocky moved midpoint session tokens from about 255k to about 89k. That is the performance story for the gate, not a claim that Grok Bot got faster at chatting.


    How does No More Slop review the code?

    No More Slop is the review skill on the same local agent. Rocky asks: is this ready for a human? No More Slop asks: does this still read like an agent wrote it?

    It scores two layers (regex slop and structural slop), rewrites against neighbor style, and rescores. Comments, motion boilerplate, verbose names, copy-paste shells. When the rest is lint, tests, or architecture, it stops pretending and hands off to Rocky.

    Without that pass, a perpetual loop just deposits AI-shaped diffs every morning. The product keeps moving. The codebase gets worse.


    Why are Rocky and No More Slop the performance?

    Grok Bot and Composer without Rocky and No More Slop is a calendar that opens noisy PRs. Speed in this setup is not "the model types faster." It is fewer wasted sessions.

    ToolJob in the perpetual appWhat breaks if you skip it
    RockyManages the engineering gates. Discovery, handbook, pre-PR verdict.Token burn, missed tests, "looks done" PRs that are not.
    No More SlopReviews the generated code so it matches the repo.Comment slop, duplicate shells, diffs a human will not want to maintain.
    Grok BotHits the right agent at the right time.Work never starts, or one bot tries to be org plus IDE.
    Composer / CursorThe local agent that actually edits the repo.Nothing lands in git.

    Rocky keeps the hit in a small context. No More Slop keeps the diff mergeable. The human still merges.


    How does the loop work?

    The perpetual application loop is: gates you add, Grok Bot organizes and hits, a Composer local agent works in Cursor behind Rocky and No More Slop, a human merges to main.

    Appzi, Clarity, Ahrefs, Sentry     (gates you add)
            |
            v
    Grok Bot team                      (Routine / PO / Developer)
      organize, schedule, HIT
            |
            v
    Composer local agent in Cursor     (does the work)
            |
            +--> Rocky                 (engineering gates, ready / not_ready)
            +--> No More Slop          (code review / slop score)
            |
            v
    PR --> human gate --> main
            |
            v
    the product stays in production    (perpetual application)

    Fixes can run every day. Features wait for Appzi (or another human signal). That is the same rule as the Grok Bot field notes. This paper only names the machinery behind the hit.


    FAQ

    What is a perpetual application? A perpetual application is a live product organized so agents keep it healthy after launch: real-user and production signals in, fixes out, features on hold until a human asks. It is not a bot that writes code all night and calls that a roadmap.

    Does Grok Bot write the code? No. The Grok Bot team organizes and hits. The local agent (Cursor, built in Composer) writes in the repo, through Rocky.

    What is Cursor Composer for? Cursor Composer is how we create the local agents. We then match each agent to a Grok Bot role. Grok Bot does not become the editor.

    Which gates can I add to a perpetual application? Start with what you already have. Appzi for voice, Clarity for behavior, Ahrefs for crawl and search, Sentry for crashes. A new gate is a new input to PO or Routine. It is not a new coding model.

    Why use Rocky and No More Slop together? Rocky manages whether the change is allowed to ship. No More Slop manages whether the change still looks like your codebase. The loop only performs if both run on the Composer agent.

    Do features ship overnight in a perpetual application? No. A perpetual application that invents screens from empty feedback is busy, not perpetual. Fixes can run on a schedule. Features wait for a human voice.


    Related