Internal tools nobody would staff, built by your agent

The workflow

1. Choose one repeated operational decision, not an entire department system. Write down the current inputs, the person who owns the outcome, the minimum records that must persist and the action that currently gets missed.
2. Give the agent a bounded prompt: Build an internal rota tool for a six-person support team. Create a weekly schedule page, store shifts and owners in Postgres, require login, record the last editor, and run a scheduled job each morning that identifies uncovered shifts. Include an operator note and an empty state. Do not add payroll or messaging integrations.
3. Have the agent build the page and application behavior in the initialized folder. The pieces are explicit: a full app page, Postgres for rota records, login for team access, one scheduled job for the daily check, and the default artifact URL. Add a Pro CNAME custom domain only if a company address matters.
4. Seed only non-sensitive test data. Walk through create, edit and empty-state paths. Confirm that access requires the intended identity and that the scheduled job produces an inspectable result rather than silently doing work no operator can verify.
5. Push and checkpoint the reviewed state, then invite the small operating group. Put the URL in the runbook or team channel where the task begins. Ask users to comment on missing fields and confusing states directly on the artifact.
6. Let the agent read the comments, revise the same workspace and publish another checkpoint. Keep the tool narrow. When requests expand into payments, regulated records or a business-critical system, reassess the architecture instead of letting a convenience tool absorb production responsibility by accident.

Setup

grain login
mkdir support-rota && cd support-rota
grain init
# Give the agent the rota prompt, then inspect the app.
grain push
grain checkpoint -m "support rota ready"
grain share --password <pw>
# Invite named people when access must be individual.

Download the Mac app first, then initialize the tool's own folder. Ask for a full app rather than a static page because records must change over time. Use Postgres for shifts, login for accountability and a scheduled job for the daily uncovered-shift check. Start on the default share address. If the team needs a company subdomain, Pro supports a custom domain through CNAME. Password sharing is useful for a quick bounded trial, while invited-person access is the clearer fit when individual team membership matters. Test the access rule, database mutations and scheduled output before treating the tool as part of operations.

What you get

• A focused internal app at a URL, built around one operational task instead of a generic platform with unused configuration.
• Postgres records that remain behind the artifact after the coding session ends, rather than state held only in a local development process.
• Login and invited-person sharing for a known team, with password and public modes available for different boundaries.
• A scheduled job tied to the workspace, suitable for the small recurring check specified in the prompt.
• An optional custom domain on Pro when the team needs the tool under a company-controlled name.
• Reader comments that can become concrete agent tasks without requiring every operator to enter the code repository.
• Ordinary files that remain exportable with grain pull, plus checkpoints that identify reviewed published states.

Proof

The honest proof is an operational acceptance test you run yourself. Create two shifts, edit one as a second invited user, sign out and confirm the login boundary, then inspect the daily check after its schedule runs. Close the authoring session and reopen the same address later. Verify that the database state remains and that a reader comment is available to the agent. Grain allows apps with Postgres, logins and scheduled jobs, and published artifacts stay published on the free tier. Those product facts define what can be tested. Whether the particular rota is correct depends on the agent's implementation and your acceptance checks, not on the publishing layer.

Limits

• A small internal tool still needs an owner. Name who reviews failures, corrects bad records and decides when the workflow changes.
• Do not place sensitive or regulated data into the app without the security, retention and access review your organization requires.
• Scheduled execution does not prove that a task succeeded. Give each job an inspectable result and a manual recovery path.
• Login controls who enters the artifact, but the agent can still write incorrect authorization logic inside the app. Test roles and data boundaries explicitly.
• Grain is not a general deployment platform or IDE. A production service with repository CI, complex integrations or formal uptime requirements may belong elsewhere.
• The free tier includes one always-on workspace. More always-on workspaces, team seats, shared spaces and custom domains are Pro capabilities.

Frequently asked questions