DEV Community: Alex Zhu

Name a Data Boundary Keeper: A One-Page Wiki SOP for What Leaves Your Laptop

Alex Zhu — Mon, 14 Sep 2026 21:29:25 +0000

Name a Data Boundary Keeper: A One-Page Wiki SOP for What Leaves Your Laptop

The failure mode this playbook prevents

The opening story is a composite scenario, not a specific incident I can cite.

Imagine your team gets free remote capacity for an agent session and moves fast to use it. On Thursday a teammate asks the agent to "make the failing auth test pass" and hands over the repository context, which quietly includes .env.staging. The session succeeds, the test passes, and a transcript containing the staging database URL lands in a shared channel three hours later. Nobody was careless in a dramatic way; the workflow simply had no named person who owned the sentence "this may leave the laptop."

That story is a composite, but the shape of it is familiar to anyone who watched remote AI tooling spread through a team faster than its rules did. The fix is not a smarter model or a stricter vendor. It is one named owner, one committed config file, and one command that runs before any context is uploaded.

Why the usual controls do not cover this

Most teams already have secret scanning at commit time and access reviews at quarter end, and both are genuinely useful. Neither answers the question a remote session raises, which is: what bytes are we about to send outside the building?

Local tooling makes that question invisible because nothing leaves your machine. Remote model access and hosted agent servers turn it into a per-task decision, and per-task decisions without an owner drift within a week. That is why a reviewer who checks "did we scan the repo" will keep missing the actual gap.

So treat the boundary as a routing problem rather than a trust problem. You are not deciding whether a provider is trustworthy; you are deciding which classes of data may go there, and who signs each decision.

Step 1 - Classify every task with a routing table

Write the table once, paste it into the wiki, and refuse to relitigate it during incidents. The right-hand column matters more than the middle one, because a rule without a signer is only a suggestion.

Data class	Typical files	Allowed destination	Signer
Public	Open-source code, published docs	Any model, any host	Task Author
Internal, no secrets	Private source, internal docs	Remote model or hosted server, after the check passes	Boundary Keeper
Secrets	`.env*`, keys, service accounts, dumps	Local session only	Boundary Keeper + Restore Reviewer
Regulated	Customer PII, health, payment data	Local only; this SOP is not sufficient	Platform or legal owner

Two rules keep the table honest over time. If a file is not on the allow list, it counts as secrets by default until the Keeper moves it. And if you cannot name the signer at that moment, the answer is local, not "probably fine."

Step 2 - Name four roles and one handoff line

Roles fail when they are fuzzy, so give every role exactly one verb and one artifact.

Task Author - describes the task, lists the minimum files the session needs, and never widens that list mid-run.
Boundary Keeper - owns .agentboundary.toml, runs the pre-flight check, and is the only person who edits the allow list.
Session Runner - starts the remote session with the approved file set only, and stops it when the ticket closes.
Restore Reviewer - reads the audit log weekly and confirms blocked patterns were fixed or promoted deliberately.

The handoff between Author and Keeper is a single line appended to the ticket, and it is the artifact auditors actually ask for later:

route=remote-ok keeper=@alex rule=v3 files=7 bytes=184320 at=2026-09-15T09:12:04Z ticket=ENG-4821

Keep that line out of chat and inside the ticket, so the decision survives the next reorg. A grep-friendly format beats a paragraph of prose describing what everyone agreed to.

Step 3 - Commit a boundary file

Put the policy inside the repository instead of inside someone's memory. This file is intentionally boring: globs, size caps, and secret patterns that reviewers can read in one pass.

# .agentboundary.toml
version = 3

[allow]
globs = ["src/**/*.py", "tests/**/*.py", "docs/**/*.md", "pyproject.toml"]
max_file_bytes = 200000
max_total_bytes = 2000000

[deny]
globs = ["**/.env*", "**/*.pem", "**/*.key", "**/id_rsa*", "**/secrets/**",
         "**/fixtures/prod/**", "**/*.sqlite", "**/*.parquet"]

[secrets]
patterns = ["AKIA[0-9A-Z]{16}", "sk-[A-Za-z0-9]{20,}", "-----BEGIN [A-Z ]*PRIVATE KEY-----"]
entropy_threshold = 4.0
min_token_length = 24

Deny always wins over allow, and the size caps matter because context is not free on any tier. The 200 KB per-file cap is arbitrary but enforceable, which is the point; choose your own number and keep it where a reviewer can see it.

Step 4 - Run the pre-flight check

The script below is a reference implementation you can adapt rather than a tool I ran against a live service while writing. It requires Python 3.11 or newer because it reads TOML with tomllib from the standard library.

#!/usr/bin/env python3
"""boundary_check.py - pre-flight gate before a remote agent session.

Reads .agentboundary.toml, checks a candidate file list, prints a verdict,
and appends one audit line. Exit codes: 0 = remote-ok, 2 = blocked, 3 = usage.
"""
from __future__ import annotations
import fnmatch, math, os, re, sys, tomllib
from collections import Counter
from datetime import datetime, timezone
from pathlib import Path

CONFIG = Path(".agentboundary.toml")
AUDIT = Path(".agentboundary.audit.log")


def shannon_entropy(value: str) -> float:
    counts = Counter(value)
    length = len(value)
    return -sum((n / length) * math.log2(n / length) for n in counts.values())


def matches_any(rel: str, globs: list[str]) -> bool:
    return any(fnmatch.fnmatch(rel, g) for g in globs)


def scan(path: Path, cfg: dict) -> list[str]:
    problems: list[str] = []
    try:
        text = path.read_text(encoding="utf-8")
    except (UnicodeDecodeError, OSError):
        return [f"{path}: not UTF-8 text, treat as local-only"]
    for pattern in cfg["secrets"]["patterns"]:
        if re.search(pattern, text):
            problems.append(f"{path}: matched secret pattern {pattern}")
    min_len = cfg["secrets"]["min_token_length"]
    for token in re.findall(r"[A-Za-z0-9+/=_\-]{%d,}" % min_len, text):
        if shannon_entropy(token) >= cfg["secrets"]["entropy_threshold"]:
            problems.append(f"{path}: high-entropy token, review before sending")
    return problems


def main(argv: list[str]) -> int:
    with CONFIG.open("rb") as fh:
        cfg = tomllib.load(fh)
    raw = argv or (sys.stdin.read().split() if not sys.stdin.isatty() else [])
    if not raw:
        print("usage: boundary_check.py FILE [FILE...]  (or pipe a file list on stdin)")
        return 3

    blocked: list[str] = []
    total = 0
    for name in raw:
        path = Path(name)
        rel = path.as_posix()
        if matches_any(rel, cfg["deny"]["globs"]):
            blocked.append(f"{rel}: denied by glob")
            continue
        if not matches_any(rel, cfg["allow"]["globs"]):
            blocked.append(f"{rel}: not on the allow list, ask the Boundary Keeper")
            continue
        size = path.stat().st_size
        if size > cfg["allow"]["max_file_bytes"]:
            blocked.append(f"{rel}: {size} bytes over the per-file cap")
            continue
        total += size
        blocked.extend(scan(path, cfg))

    if total > cfg["allow"]["max_total_bytes"]:
        blocked.append(f"total payload {total} bytes over cap")

    verdict = "BLOCK" if blocked else "REMOTE_OK"
    stamp = datetime.now(timezone.utc).isoformat(timespec="seconds")
    line = (f"{stamp} verdict={verdict} keeper={os.environ.get('BOUNDARY_KEEPER', 'unset')} "
            f"files={len(raw)} bytes={total}")
    with AUDIT.open("a", encoding="utf-8") as fh:
        fh.write(line + "\n")
    print(line)
    for item in blocked:
        print(f"  - {item}")
    return 2 if blocked else 0


if __name__ == "__main__":
    raise SystemExit(main(sys.argv[1:]))

Wire it into the ticket workflow with two commands, one for a quick audit of the whole tree and one for the exact file set a session will use:

# Audit what the tree currently contains
git ls-files -co --exclude-standard | BOUNDARY_KEEPER=@alex python3 boundary_check.py

# Approve one ticket's minimal payload
BOUNDARY_KEEPER=@alex python3 boundary_check.py src/agent/runner.py tests/test_runner.py
echo "exit=$?"

A blocked run should look boring and specific, which is what makes it actionable:

2026-09-15T09:12:04+00:00 verdict=BLOCK keeper=@alex files=7 bytes=0
  - .env.staging: denied by glob
  - tests/fixtures/urls.txt: high-entropy token, review before sending

Step 5 - Paste the one-page run into the wiki

A numbered run that fits on one screen beats a policy document nobody opens during a deadline push.

Task Author opens the ticket and lists the minimum files the session requires.
Boundary Keeper confirms each path against the routing table and runs the check.
If the verdict is BLOCK, Author trims the payload or swaps secrets for fixtures.
Keeper appends the handoff line and approves with an explicit timestamp.
Session Runner starts the remote session with only those paths available to it.
Runner closes the session at ticket close; no long-lived background loops.
Restore Reviewer reads the weekly audit log and proposes config changes as pull requests.
Anyone may revoke an approval; stop the session first, then ask questions.

Steps five and six are where most leaks happen in practice, because a session left running keeps reading whatever the working tree happens to contain. If your team only remembers one line from this article, remember that one.

Limitations, and who should not use this

Be honest about the ceiling here. Glob rules and entropy checks catch careless mistakes; they do not inspect what happens to data after upload, and they cannot enforce provider-side retention or training policies.

Entropy heuristics also cut both ways. Minified bundles and base64 fixtures trip the threshold, while a short but valid credential can slip underneath it, so expect to tune min_token_length for your repository instead of trusting the default. Treat every BLOCK as a conversation starter, not a verdict from a scanner.

The SOP is a social control, not a sandbox. If you need a hard technical boundary, put an egress proxy or a DLP tool in front of the session and keep this file as the human-readable companion.

Do not use this approach on its own for regulated data, contractual restrictions, or anything your security team classifies as sensitive. If you cannot get a named Boundary Keeper with real authority to say no, writing the role down will not change anything.

Where a free remote session fits into the workflow

MonkeyCode is relevant here because the project offers free model access and a free server option, and the free server option is exactly the case this playbook was written for: the session runs somewhere other than your laptop. The operator states an allowance of 10 million free tokens, so verify the current terms on the project itself before you plan capacity around it.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

A sane first run on any free tier looks like this. Pick one small ticket, commit .agentboundary.toml with a conservative allow list, run the checker, and send only the approved paths into the session. Then compare the audit log against what the session actually touched, and tighten the file before you widen it.

Most teams discover the same thing at that point, which is that the boundary file is the cheap part and the named owner is the hard part. If you want to try the workflow, start with the checker on a single ticket rather than migrating an entire repository into a hosted session.

Name a Tool Budget Owner: A One-Page Wiki SOP for Shared Agent Runs

Alex Zhu — Sun, 13 Sep 2026 19:36:07 +0000

You come back from lunch to a shared lab chat that looks like an incident channel. The agent you started before noon has issued dozens of shell commands against one failing test. A teammate cannot push a hotfix because repeated pytest artifacts have filled the shared workspace disk. Nobody can say who is allowed to kill the process, so the retry loop keeps going.

This is not a model-quality problem in most small teams; it is an ownership problem. Cheap retries feel harmless until the same failing command runs for an hour on a machine other people still need. Without a named Tool Budget Owner, every extra shell call looks reasonable in isolation. You need a one-page wiki SOP before the next shared spike, not another prompt tweak.

What actually burns the shared lab

Most coding agents are a planner wrapped around tools: shell, file edits, test runners, and sometimes git. The planner will keep calling those tools while the transcript still looks like progress. On a laptop you notice the fan. On a shared host you notice a blocked push, a wedged port, or a teammate asking who owns the process.

You should treat tool calls as a budget the same way you treat deploy windows. A budget needs a person, a written cap, and a stop action that does not require a meeting. If you skip those three pieces, the agent becomes an unpaid intern with root-adjacent shell and no timesheet.

Four roles you can paste into the wiki

Keep the roster tiny so a Friday spike still has names attached. Write full names and a backup, not a rotating emoji.

Tool Budget Owner — sets caps, allowlists, and the kill/park/transfer rule for this run.
Runner — starts the agent, records the transcript path, and stays reachable for one working session.
Reviewer — reads tool output that touched git, secrets, or production-shaped config before merge.
Host Steward — owns the shared machine or workspace and can reclaim disk, ports, and processes.

The Tool Budget Owner may be the Runner on a two-person team, but the names still go on the page. When one person holds two hats, write that explicitly so a third teammate does not assume coverage. If the Owner will be offline, transfer the page before the agent starts, not after the first retry storm.

The one-page run (copy this block)

Paste the following into your team wiki and fill the brackets. Do not start the agent until every bracket has a value or an explicit n/a.

# Tool budget run — [date] — [repo]

- Tool Budget Owner: [name] (backup: [name])
- Runner: [name]
- Reviewer: [name]
- Host Steward: [name]
- Workspace / host: [path or hostname]
- Goal (one sentence): [what done looks like]
- Hard stop time: [local time]
- Max tool calls: [n]
- Max consecutive retries of the same command: [n]
- Max files touched: [n]
- Command allowlist file: tool-budget.yaml
- Transcript path: [absolute path]
- On cap hit: kill | park | transfer to [name]
- Secrets rule: no .env, no cloud creds, no production kube contexts

Read the page out loud with the Runner before launch. If you cannot say the stop action in one sentence, the run is not ready. Update the page when you transfer ownership; a stale name is worse than a missing name.

A policy file the Owner can enforce

Proposed example — adapt the numbers to your lab; they are not measured defaults. Keep the file in the repo so the cap travels with the spike.

# tool-budget.yaml
version: 1
run:
  hard_stop_local: "18:00"
  max_tool_calls: 40
  max_same_command_retries: 3
  max_files_touched: 12
allow_commands:
  - pytest
  - ruff
  - python
  - git status
  - git diff
deny_path_globs:
  - ".env"
  - ".env.*"
  - "**/credentials.json"
  - "**/*kubeconfig*"
write_roots:
  - "src/"
  - "tests/"
  - "docs/"
on_cap:
  action: park   # kill | park | transfer
  park_dir: ".agent-park/"

The allowlist is supposed to feel tight. If your agent needs git commit or docker, add those lines in the wiki change, not in a hidden prompt. The Host Steward should reject a run whose policy includes bash -c with no further constraint, because that cap is theater.

A watchdog you run beside the agent

Proposed example — this script does not claim to sandbox the model. It only reads a JSONL transcript your Runner already writes, then prints a stop code the Host Steward can bind to kill.

# tools/check_tool_budget.py
from __future__ import annotations

import json
import sys
from collections import Counter
from pathlib import Path

import yaml

EXIT_OK = 0
EXIT_PARK = 2
EXIT_KILL = 3


def load_policy(path: Path) -> dict:
    return yaml.safe_load(path.read_text())


def load_events(path: Path) -> list[dict]:
    events = []
    for line in path.read_text().splitlines():
        if line.strip():
            events.append(json.loads(line))
    return events


def main() -> int:
    policy = load_policy(Path(sys.argv[1]))
    events = load_events(Path(sys.argv[2]))
    commands = [e.get("command", "") for e in events if e.get("type") == "tool"]
    files = [e.get("path", "") for e in events if e.get("type") == "write"]
    retries = Counter(commands)

    if len(commands) > policy["run"]["max_tool_calls"]:
        print("cap: max_tool_calls")
        return EXIT_PARK
    if retries and retries.most_common(1)[0][1] > policy["run"]["max_same_command_retries"]:
        print("cap: max_same_command_retries")
        return EXIT_PARK
    if len(set(files)) > policy["run"]["max_files_touched"]:
        print("cap: max_files_touched")
        return EXIT_PARK

    denied = tuple(policy["deny_path_globs"])
    for path in files:
        if any(Path(path).match(glob) for glob in denied):
            print(f"kill: denied path {path}")
            return EXIT_KILL
    print("ok")
    return EXIT_OK


if __name__ == "__main__":
    raise SystemExit(main())

Wire it to a loop the Runner already understands. Keep the commands boring so a substitute Host Steward can run them from the wiki.

python3 tools/check_tool_budget.py tool-budget.yaml /tmp/agent-transcript.jsonl
code=$?
if [ "$code" -eq 2 ]; then
  mkdir -p .agent-park
  mv /tmp/agent-transcript.jsonl ".agent-park/$(date +%Y%m%dT%H%M%S).jsonl"
  pkill -f "your-agent-entrypoint" || true
elif [ "$code" -eq 3 ]; then
  pkill -9 -f "your-agent-entrypoint" || true
fi

Label the transcript format in the wiki if your agent SDK uses different keys. The point is a stop code, not a perfect parser. If the agent cannot emit JSONL, have the Runner wrap each tool call with a one-line logger; that wrapper is cheaper than arguing about vendor formats.

Decision table for the stop action

Use this table when the watchdog prints a cap. The Tool Budget Owner picks one cell before the run, not during the storm.

Signal	Default action	You park when	You kill when
Tool call cap hit	park	Goal is still valid after lunch	Host is blocking other work
Same command retried past cap	park	Flaky test, human will rerun	Command mutates git or infra
File-touch cap hit	park	Extra files are docs or fixtures	Writes escaped `write_roots`
Denied path glob	kill	Never park on secrets	Always kill, then rotate if needed
Hard stop time	transfer or kill	Owner going offline	Steward needs the host back

Park means freeze the transcript and leave a note in the wiki. Kill means terminate the process and reclaim disk. Transfer means a named human takes the page before the next tool call.

Where a free model and free server fit

Shared labs often pick a workspace that already offers free model access and a free server option so a spike does not wait on a procurement thread. If that workspace is MonkeyCode, treat those two options as finite shared capacity: they make the first agent run easy, and they make an unbounded retry loop easy as well. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The SOP does not depend on one vendor. You still name an Owner, write caps, and store transcripts outside the chat window. The free server is just another host the Steward can reclaim. The free model is just another planner that will keep calling tools until you stop it.

Put the wiki page URL in the workspace README so a guest Runner cannot claim they never saw the caps. If you change allowlists mid-run, stop the agent first; a live policy edit is how two teammates enforce different budgets on one process.

A short launch checklist

Walk these steps in order. If you skip a number, you do not have a run; you have a hope.

Create the wiki page from the template and fill every bracket.
Commit tool-budget.yaml on a branch that is not main.
Confirm the Host Steward can pkill the entrypoint without asking in chat.
Start transcript logging before the first tool call, not after the first failure.
Run the watchdog on an interval the Owner can live with, such as every two minutes.
Stop at the first cap, update the wiki with the stop action, then decide whether to continue.

You can keep a dry-run habit: feed a previous transcript into check_tool_budget.py before you trust the caps. That check is a proposed rehearsal, not a published benchmark. If the script parks a run you still liked, lower the ambition of the goal rather than raising the cap in secret.

Limitations

This playbook does not sandbox the model, and it does not replace code review. A determined agent with unrestricted shell can ignore your YAML unless the Steward wraps the process. The watchdog only sees events you log, so a silent side channel will not trip a cap.

It also does not decide whether the patch is correct. Pair it with whatever review gate you already use for AI-authored diffs. Caps prevent a retry storm; they do not prevent a confident wrong edit that fits inside the budget.

Do not treat the sample numbers as capacity planning. Forty tool calls may be huge for a docs-only spike and tiny for a flaky integration suite. Write numbers your Host Steward can defend on Monday.

Who should not use this approach

Skip this SOP if you are the only person on a personal laptop and you can hear the fans. You still might want a retry cap, but you do not need four wiki roles. Skip it if your company already wraps agents in a job scheduler with quotas, audit logs, and an on-call rotation that pages on runaway processes.

Do not use a free shared server for data you cannot paste into a vendor workspace. This article does not claim retention behavior, isolation, or uptime. If the repo contains production secrets, regulated patient data, or customer exports, keep the agent off that host and off those files.

If your teammates will not name an Owner in writing, stop there. A beautiful YAML file with no human attached is how Friday retry storms start. Name the Tool Budget Owner first, then let the agent touch the repo.

Name an Eval Owner: A Wiki SOP When AI Writes the Tests Too

Alex Zhu — Sat, 12 Sep 2026 17:39:41 +0000

You have already seen this pattern on a shared lab board more than once this quarter. A teammate pastes a failing ticket into a coding assistant, accepts a full patch, and watches generated tests turn green. Nobody notices that the same session invented both the implementation and the assertions that bless it. The next on-call person inherits a merge that looks locally green and then fails in production.

This playbook names one human as Eval Owner before any AI-heavy pull request can merge. You keep the assistant, including free model access on a shared host, but you stop treating model-written tests as independent evidence. The artifact below is a one-page wiki SOP, a four-role handoff, and a small Python check you can run without the original chat.

The failure you are actually debugging

Shared free coding loops make this failure cheap to create and later expensive to notice during review. Someone drives a long session on a borrowed machine, dumps a patch plus tests, and leaves before standup. Reviewers skim the diff, trust the green squares, and never ask who authored the oracle that blessed the change. When the oracle and the code share one prompt, you have a tautology rather than a real test.

You do not need a new framework to interrupt that loop on a busy shared board. You need a named owner, a written bar, and a handoff that survives the person who closed the laptop. Write those three things on one wiki page so the next reader can replay the check without hunting through chat logs.

Current discussion about assistants drafting entire diffs makes this independence gap louder rather than smaller for shared labs. Faster patches increase the chance that tests and code are born together inside a single unreviewed thread. Your job is not to ban the assistant; your job is to keep the oracle out of that generating thread.

Four roles you paste into the wiki

Assign these names on the ticket before the first assistant prompt, not after the pull request already exists. If you skip the naming step, the Implementer silently becomes the Eval Owner and the Reviewer inherits a circular suite. Put the four handles where a tired reviewer will see them without opening extra documents or old threads.

Eval Owner. This person writes or selects checks that the coding session is not allowed to edit after freeze. They own fixtures, expected errors, and the replay command that a newcomer must be able to run.
Implementer. This person may use an assistant for code, refactors, and throwaway sketches against the frozen bar. They must not rewrite expected outputs so a convenient patch can turn the suite green.
Reviewer. This person confirms the suite is independent, readable, and actually fails against a known-bad stub. They run the wiki command on a clean checkout, not on the Implementer's already-tuned laptop.
Rollback Contact. This person stays reachable until the change is parked, reverted, or transferred to a named successor. Silence from this role means the pull request stays parked instead of drifting into an unowned merge.

If one person holds two roles, write that exception on the wiki page before work starts. Dual-hat work is allowed for tiny chores, but Eval Owner and Implementer should stay split for money, auth, or retained user data. A missing backup name is a parked ticket, not an invitation for whoever is awake to rewrite fixtures.

Decision table: is the eval independent?

Use this table in the pull request body so reviewers can score independence without rereading the whole assistant thread. If you cannot fill a row honestly, you do not yet have an eval, and the merge bar stays closed. The table is a conversation tool, not a score that you game by renaming generated tests as fixtures.

Question	Pass	Fail	Owner action
Who authored the fixtures?	A human Eval Owner, or a frozen file from before the session	The same chat that wrote the code	Reject and regenerate fixtures offline
Does a known-bad stub fail?	At least one mutation fails the suite	Suite stays green against an empty parser	Add a negative case before review
Can a newcomer replay without the chat?	A wiki command produces the same pass or fail	Replay needs the original thread or a hidden prompt	Record the command and pin the fixture hash
May the Implementer edit evals?	No, except typo fixes the Reviewer accepts	Yes, freely, in the same commit as the feature	Split commits or block merge

Numbered run: one page you can paste today

Copy the steps into your team wiki and fill the names before anyone opens a coding assistant. Keep the page to one screen so tired people will still follow it during a late review. If the page grows past a scroll, you have started writing a process novel instead of a runbook.

Name the Eval Owner on the ticket. Write the person's handle, timezone, and a backup before anyone opens an assistant. Do not start prompting until this line exists on the wiki page for that ticket.
Freeze the oracle before the assistant sees the production code path. Put fixtures, example payloads, and expected errors in a directory the Implementer cannot treat as draft. Share that path in the ticket so review does not hunt through personal scratch files.
Record the replay command in the same page. One shell line should run the independent suite from a clean checkout. If it needs extra env vars, list them beside the command instead of burying them in chat.
Run a negative check that a stub must fail. Point the suite at an empty or mutated parser and confirm it fails loudly. If the stub still passes, your oracle is too weak to serve as a merge bar.
Allow the Implementer to use an assistant after freeze. They may generate code against the frozen bar and iterate on implementation details. They may not rewrite expected outputs to match a convenient patch during that session.
Reviewer executes the wiki command on a clean checkout. Green results from the Implementer's laptop are not evidence for merge. Replay from the recorded command is the only evidence the Reviewer should accept.
Rollback Contact stays named until the next written handoff. If the owner goes offline, park the pull request rather than silently inheriting the bar. Transfer requires a new Eval Owner handle on the same wiki page.

One-page wiki template

Paste this block, then replace the brackets with handles, hashes, and a replay command that actually runs. Do not grow it into a novel, and do not hide the rollback contact below a fold of extra commentary. A short page that people use will beat a perfect page that nobody opens during review.

# Eval bar — [ticket id] — [date]

- Eval Owner: [@name] (backup [@name])
- Implementer: [@name]
- Reviewer: [@name]
- Rollback Contact: [@name] until [date/time]

## Frozen oracle
- Fixture path: `evals/invoice_totals.v1.json`
- Fixture sha256: [hash]
- Replay: `python evals/check_invoice_totals.py --fixtures evals/invoice_totals.v1.json`
- Negative replay: `python evals/check_invoice_totals.py --fixtures evals/invoice_totals.v1.json --mutate empty --expect-fail`

## Session notes
- Assistant host: [shared lab / local / other]
- System prompt frozen? yes/no
- Implementer edited evals? yes/no — if yes, Reviewer sign-off: [@name]

## Handoff
- Park / merge / revert: [choice]
- Next owner if parked: [@name]

A replayable check the chat does not own

The script below is an example you can run locally against a frozen oracle the chat does not own. It treats fixtures as the source of truth and refuses to proceed when the oracle file is missing. Label it as a template if your domain objects, locales, or error types differ from this invoice sketch.

# evals/check_invoice_totals.py
from __future__ import annotations

import argparse
import json
import sys
from pathlib import Path


def load_oracle(path: Path) -> list[dict]:
    if not path.is_file():
        raise SystemExit(f"oracle missing: {path}")
    payload = json.loads(path.read_text(encoding="utf-8"))
    if not isinstance(payload, list) or not payload:
        raise SystemExit("oracle must be a non-empty list")
    return payload


def parse_total(raw: str) -> str:
    """Replace this stub with the implementation under test."""
    digits = [ch for ch in raw if ch.isdigit() or ch in ".-"]
    if not digits:
        raise ValueError("no amount found")
    return "".join(digits)


def parse_total_empty(raw: str) -> str:
    return ""


def main() -> int:
    parser = argparse.ArgumentParser(description="Independent invoice total oracle")
    parser.add_argument("--fixtures", required=True)
    parser.add_argument("--mutate", choices=["none", "empty"], default="none")
    parser.add_argument("--expect-fail", action="store_true")
    args = parser.parse_args()

    fn = parse_total_empty if args.mutate == "empty" else parse_total
    cases = load_oracle(Path(args.fixtures))
    failures = []
    for case in cases:
        sample = case["input"]
        expected = case["expected"]
        try:
            got = fn(sample)
        except Exception as exc:  # example path; tighten in real code
            got = f"error:{exc.__class__.__name__}"
        if got != expected:
            failures.append((sample, expected, got))

    if args.expect_fail:
        if failures:
            print("negative check passed: oracle rejected the stub")
            return 0
        print("negative check failed: stub unexpectedly matched oracle")
        return 1

    if failures:
        for sample, expected, got in failures:
            print(f"oracle mismatch input={sample!r} expected={expected!r} got={got!r}")
        return 1

    print(f"oracle ok cases={len(cases)}")
    return 0


if __name__ == "__main__":
    sys.exit(main())

A tiny fixture file keeps the session honest because the assistant did not author it during the coding loop. Commit that file in a separate change, or at least before the Implementer starts prompting against the ticket. If the model proposes new expected values, the Eval Owner treats that proposal as a change request, not as truth.

[
  {"input": "Total due: USD 1,204.50", "expected": "1204.50"},
  {"input": "amount missing", "expected": "error:ValueError"}
]

Run the positive path and the negative path as two commands so the wiki replay line stays obvious to newcomers. Keep both commands on the wiki page rather than inside a personal alias that nobody else can find.

python evals/check_invoice_totals.py --fixtures evals/invoice_totals.v1.json
python evals/check_invoice_totals.py --fixtures evals/invoice_totals.v1.json --mutate empty --expect-fail

Hash the fixture after the Eval Owner freezes it, then paste the digest into the wiki page next to the path. If the Implementer's branch changes that hash, the Reviewer treats the eval as contaminated and restarts from freeze. Do not accept a verbal claim that the file only changed whitespace; the digest is the handoff artifact.

shasum -a 256 evals/invoice_totals.v1.json

Where a free shared coding host fits

Teams often run these loops on whatever machine is idle, then lose the thread that produced the patch. A shared coding environment with free model access and a free server option can host the Implementer's session without mixing personal billing. The Eval Owner still keeps oracles in version control that the chat cannot quietly edit.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

MonkeyCode is one such option when you want the Implementer on a free model path. Keep fixtures in a repository the assistant does not control, even when the coding session runs on that shared host. If you try the SOP there, paste the wiki page first and keep the four handles visible in the pull request.

Limitations

This SOP does not prove the product is correct for every caller, locale, or production shape you will meet. It only proves the merge bar is independent of the generating session that proposed the patch. Property tests, contract tests, and production monitors still matter, and none of them replace a Reviewer who can read the domain.

Free model access and a free server option can change, pause, or move without notice from any vendor. You must not pin incident response to a particular host, queue, or assistant thread that might vanish overnight. Do not store secrets in the assistant thread, and do not treat generated tests as compliance evidence for auditors. The Python snippet is an example, not a library, and you should adapt types, errors, and locale rules before money paths.

Who should not use this approach

Skip this playbook if you already require independently authored tests and your review checklist already fails tautological suites. Skip it if a single volunteer is pretending to be four roles on a regulated workload with real customers. Skip it if your fixtures themselves come from production data you cannot legally copy onto a shared host.

You should also skip it when the change is a comment-only edit or a docs typo that cannot break behavior. Naming an Eval Owner for those chores trains people to ignore the page the next time a parser changes. Save the ritual for patches where a green suite could hide a shared wrong assumption about inputs.

Close the loop in standup, not in the chat

Ask one question at standup: who owns the eval bar for each open AI-heavy ticket on the board. If the answer is the model or whoever prompted last, you do not have a bar yet. Write the name, freeze the oracle, and only then let the assistant write code against a check it does not own.

Name a Diff Signer: A One-Page Wiki SOP for AI-Authored Patches

Alex Zhu — Fri, 11 Sep 2026 15:20:53 +0000

You open the shared repository on Monday morning and find three pull requests already merged into main. The commit messages mention an agent loop, a free host, and a late Friday experiment that ran too long. Nobody on the team can replay the session, because the shared free server no longer holds that chat. You are now the person who must decide whether those diffs stay, get reverted, or wait for a signer.

Shared free-tier coding loops fail in a boring way that looks like velocity until review is missing. The model will draft a patch, the host will keep the process alive, and git will still record a merge. Git will not record a human who read the blast radius after the chat history vanished. This playbook gives you a signer window, three named seats, and a one-page wiki run you can paste.

The failure you are actually gating

An AI-authored patch is not a complete change until a named human accepts the blast radius in git. Tool traces vanish when a free session ends, so the agent is not an owner and not an audit trail. You need a signer who can still explain the diff after the chat history is gone for good. You also need that name written before tokens start moving, not after main has already gone red.

Waiting until Monday morning trains the team to treat silence as consent on unsigned merges. The SOP below treats a missing signer as a failed gate, the same way missing tests fail a build. Social memory will not survive a long weekend, which is why the wiki page has to be boring and short. If you cannot point to a handle, you do not have a review; you have a hope.

Three seats and one signer window

Fill three seats on one wiki page before anyone launches a shared coding loop. Keep overnight ownership, topology guesses, and staging gates on other pages so this run stays about the diff. The loop starter is a duty, not a fourth throne, and that duty can rotate every spike.

Diff signer — the human who reads the patch and writes SIGNER: @handle on the pull request.
Merge captain — the person allowed to press merge after the signer line exists and the window is still open.
Rollback owner — the person who reverts within an agreed window if CI or production complains.

The person who starts the loop and the diff signer must be different people whenever two humans are available. If you are alone, you still write your name in the signer seat, then you wait one sleep cycle before merging auth, billing, or deletion paths. That pause is the control; skip it and the SOP is only theater. Name the rollback owner before the first tool call, because finding a volunteer after main breaks is not a handoff.

The one-page wiki run you can paste

Copy the block below into your team wiki. Replace the bracketed fields before the loop, not after the revert. Keep the page short enough to read in two minutes on a phone.

# Diff-Signer SOP (AI-authored patches)

Status: ACTIVE
Lab date (UTC): YYYY-MM-DD
Shared host: [workstation or free server label]
Model access: [free-tier label only; no guessed quotas]
Repository: [org/repo]
Branch: [topic branch]
Loop starter (duty): [@handle]
Diff signer: [@handle]
Merge captain: [@handle]
Rollback owner: [@handle]
Signer window: [start UTC] → [end UTC]
Path allowlist: [src/app/ docs/]
Out of scope: [secrets, lockfiles, prod Terraform]
Rollback window: [example: 4 hours after merge]

## Gate
- No merge to main without `SIGNER: @handle` in the PR body.
- No merge if the signer window has expired.
- No merge if the rollback owner is offline and the diff touches infra.

## After the loop
- PR URL:
- Commit SHA:
- Signer read the diff without the chat transcript: [yes/no]

If the page grows past one screen, you are mixing runbooks. Split host health, prompt topology, and overnight coverage away from this signer page. A wiki that tries to govern every AI fear will not get filled on Friday. Empty fields mean the loop does not start.

Steps for the person who starts the loop

Follow these steps in order. Do not start the agent until step four is green on the wiki page.

Create a topic branch from an updated default branch and push it empty, so the pull request exists before the model writes files.
Open the wiki page, fill every seat, and ping the diff signer in chat with the page link and the allowlist.
Write a path allowlist in the pull request body so the loop cannot wander into secrets, lockfiles, or production Terraform.
Wait for the signer to reply window open on the wiki page; if they do not reply, you do not start the loop.
Run the coding loop only against the topic branch, and stop when the signer window ends, even if the agent wants one more file.
Push the diff, paste the pull request URL onto the wiki page, and walk away without merging.

Here is a small command sequence you can paste. Treat it as a proposal until you have run it in your own clone.

# Proposal: create the review branch before the agent writes anything
git fetch origin
git switch -c lab/ai-patch-$(date -u +%Y%m%d) origin/main
git push -u origin HEAD

# Proposal: open a PR with a signer placeholder the local check can read
gh pr create --title "lab: AI patch pending signer" --body "$(cat <<'EOF'
SIGNER: UNASSIGNED
ROLLBACK: @handle
ALLOWLIST: src/app/ docs/
WIKI: https://wiki.example/diff-signer-sop
EOF
)"

If your team does not use gh, create the same pull request in the browser and keep SIGNER: as the first line of the body. The important part is the token in the body, not the CLI flavor. An empty branch with a real pull request beats a local pile of unreviewed files on a laptop.

Steps for the person who signs the diff

You are not reviewing the model's personality. You are reviewing a git diff that must survive after the free session disappears. Read the tree first, then read any chat transcript only if the tree is already defensible.

Open the pull request without opening the chat transcript first, so you judge the files, not the story the agent told.
Reject the patch if it touches paths outside the allowlist, even when the change looks clever or the commit message sounds confident.
Reject the patch if you cannot explain the failure mode in one sentence on the wiki page beside the SHA.
If you accept, replace SIGNER: UNASSIGNED with SIGNER: @yourhandle and a UTC timestamp inside the pull request body.
Tell the merge captain the window is still open, and do not merge if you also started the loop and a second human exists.

A useful local inspection looks like the commands below. Run them against the remote topic branch, not against a working tree the agent still owns.

git fetch origin
git diff origin/main...origin/lab/ai-patch-20260911 --stat
git diff origin/main...origin/lab/ai-patch-20260911

Read the stat output before the full diff so the size of the change is visible. If more than a handful of files moved, you probably do not have a signer window; you have a rewrite. Rewrites need a different playbook, a longer window, and a merge captain who is awake.

A local signer check you can reproduce

The artifact below is a small Python gate. It reads a pull-request body from a file and fails when a real signer line is missing. Save it as tools/check_signer.py and run it on your laptop before anyone presses merge.

#!/usr/bin/env python3
"""Fail if an AI-authored PR body has no human SIGNER line.

Example gate: run it against a saved PR body file.
It does not call a vendor API and does not prove the human read the diff.
"""
from __future__ import annotations

import re
import sys
from pathlib import Path

SIGNER_RE = re.compile(
    r"^SIGNER:\s*@?(?P<name>[A-Za-z0-9][A-Za-z0-9_-]{1,38})\s*$",
    re.MULTILINE,
)
FORBIDDEN = {"unassigned", "none", "n/a", "agent", "bot", "model"}


def load_body(path: Path) -> str:
    if not path.is_file():
        raise SystemExit(f"missing PR body file: {path}")
    return path.read_text(encoding="utf-8")


def find_signer(body: str) -> str | None:
    match = SIGNER_RE.search(body)
    if not match:
        return None
    return match.group("name")


def main(argv: list[str]) -> int:
    target = Path(argv[1]) if len(argv) > 1 else Path("pr_body.txt")
    body = load_body(target)
    signer = find_signer(body)
    if signer is None:
        print("FAIL: no SIGNER: @handle line in pull request body")
        return 2
    if signer.lower() in FORBIDDEN:
        print(f"FAIL: signer {signer!r} is a placeholder, not a human")
        return 2
    print(f"PASS: signer is {signer}")
    return 0


if __name__ == "__main__":
    raise SystemExit(main(sys.argv))

Save a sample body and run the check twice so both paths are visible.

printf 'SIGNER: UNASSIGNED\nALLOWLIST: src/\n' > pr_body.txt
python3 tools/check_signer.py pr_body.txt
# expected: FAIL

printf 'SIGNER: @alex\nALLOWLIST: src/\n' > pr_body.txt
python3 tools/check_signer.py pr_body.txt
# expected: PASS

Treat those commands as unexecuted in your environment until you have run them once on a throwaway file. The script does not prove the human read the diff; it only proves the team refused to merge with a blank owner. That is a weak control, and it is still stronger than a chat that vanished with the free session.

If you later wire a forge workflow, keep it equally small. The following snippet is a proposal, not a production pipeline, and you should run it in a fork before trusting it on shared main.

# Proposal only — unexecuted in this article
name: signer-gate
on:
  pull_request:
    types: [opened, edited, synchronize]
jobs:
  signer:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Write PR body
        env:
          BODY: ${{ github.event.pull_request.body }}
        run: printf '%s\n' "$BODY" > pr_body.txt
      - run: python3 tools/check_signer.py pr_body.txt

How a free model server changes the record

Some shared labs point the coding loop at MonkeyCode's free model access and free server option when a spike is cheap enough to discard. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Keep the signer window anyway, because that host is not a substitute for a named human on the pull request.

Do not treat a free host as a durable log of tool calls or prompt retries. Session state can disappear, so the wiki page and the git history are the records you keep. Do not invent quotas, model names, or uptime promises on the wiki; write only the lab date, the branch, and the three handles. If the free server is busy or unavailable, you park the loop and you do not move an unsigned diff onto a laptop.

After the window: a small decision table

Print this table under the wiki SOP so Friday-you does not invent a fourth outcome. Tables survive a long weekend better than tribal memory, and they give the merge captain something to point at besides mood.

Condition	Action	Who acts
Signer line present, allowlist clean, tests green	Merge	Merge captain
Signer line present, tests red	Hold; do not expand the loop	Loop starter
Signer window expired	Close or convert to draft	Merge captain
Diff escaped the allowlist	Refuse merge; reset the topic branch	Diff signer
Merge already happened, rollback window open, CI or prod complains	Revert the SHA	Rollback owner
Chat transcript gone, no signer line	Treat as unsigned; revert if already on main	Rollback owner

If two rows seem to apply, take the stricter action and write one sentence on the wiki about why. Do not reopen the agent to "just tidy the tests" after the signer window has closed. A second loop is a new page, a new window, and a new ping, not a continuation hidden inside the same pull request.

Limitations and who should skip this

This playbook does not make the model safer, faster, or more accurate, and it does not recover a deleted session. It only makes ownership visible after the chat dies. The Python gate can be spoofed by typing a teammate's handle, so you still need chat pings and the social cost of putting a name on a bad diff. The extra latency will annoy anyone who wanted the agent to land on main before lunch, which is an intended cost rather than a defect in the steps.

You should not use this SOP if a regulated CODEOWNERS flow already blocks merges and a second theater gate would hide the real owners. You should not use it for incident hotfixes that already have a named commander and a recorded bridge. You should not point unsigned agent loops at production credentials on any host, free or paid. Solo developers can still use the signer line as a note to future-you, but the two-person split will not exist, so keep the sleep-cycle pause for dangerous paths.

If you already have a free server for spikes, paste the wiki block before the next loop rather than after the Monday revert.

Kill, Park, or Transfer: Overnight Ownership for Shared Free AI Loops

Alex Zhu — Thu, 10 Sep 2026 04:16:13 +0000

You shut the lid on Friday while a coding agent still iterates against a shared free server. The loop looks harmless because it is only a rehearsal spike, not customer-facing production traffic. Monday morning a teammate finds the box busy, the prompt undocumented, and the stop condition missing. Shared free AI stays useful until overnight ownership evaporates, after which the rehearsal quietly becomes a blocker.

Agentic tool loops make this failure mode sharper than a forgotten notebook process. The agent keeps assuming it may call tools, retry failures, and hold the only warm runtime on the host. Your team does not need another glossary of agent terms; you need named humans, a written stop rule, and a paste-ready handoff. This playbook gives you four roles, one wiki page, and a session card you can generate from the shell.

What this SOP is for

Treat every long-running agent session as a borrowed machine, not a private scratch buffer. You are sharing model access, disk, and a process table with people who also have Friday spikes. If the loop can continue after you disconnect, it needs an owner who will still answer Slack. If nobody will answer, the default action is park or kill, never hope.

This article stays useful on any shared box. The free-model and free-server option discussed later is only one place you might rehearse. Do not promote an overnight loop into production routing until the session card is complete and a reviewer has signed the transfer line.

Four roles you assign before the loop starts

Do not start the agent until these four names exist, even when two names belong to the same person. Write the names on the wiki page first, then start the process, not the other way around.

Experimenter — writes the prompt, tool allowlist, and the hypothesis the loop is testing.
Session owner — remains accountable while the process lives, including nights and weekends.
Incoming owner — the human who accepts the next shift and may kill the process on sight.
Reviewer — a second person who can veto continued spend, extra tool access, or any promotion talk.

If you cannot name an incoming owner for the next twelve hours, you do not have a session owner either. In that case you park the work with a card, or you kill the process before you leave. Shared rehearsal hosts fail when “someone will check it tomorrow” is the only runbook.

The one-page wiki you can paste today

Copy the block below into your team wiki and fill every field before python starts. Empty fields are a failed handoff, not a flexible culture. Keep the page to one screen so the incoming owner can read it on a phone.

# Agent session card (kill / park / transfer)

- Experiment id:
- Hypothesis (one sentence):
- Data class: public-sample / synthetic / **no customer data**
- Host: (shared rehearsal server only)
- Working directory:
- PID / container id:
- Started at (UTC):
- Must stop at (UTC):
- Experimenter:
- Session owner (on the hook now):
- Incoming owner (next shift):
- Reviewer (veto):
- Tool allowlist (exact):
- Forbidden actions:
- Stop condition (tokens, errors, wall clock, or test gate):
- How to kill (exact command):
- How to park (artifact path):
- Transfer notes for the next human:
- Decision: kill | park | transfer
- Sign-off timestamps:

Print that page beside the process list. If the card and the live process disagree, the process is wrong, and the incoming owner kills it. Do not negotiate with a loop that outlived its card.

Numbered handoff run

Run this sequence at every shift change, including a quiet Friday evening. Skipping a step is how orphan loops survive until Monday.

Outgoing owner freezes input. Stop feeding new files or extra tools into the agent. Record the last prompt hash or file path on the card. You are handing a snapshot, not a moving target that keeps mutating in chat.
Outgoing owner writes the kill command. Paste the exact shell line, not a vague “stop the python thing.” Include working directory and container name if you used one. The incoming owner must be able to execute it without guessing flags.
Outgoing owner chooses kill, park, or transfer. Use the decision table below; do not invent a fourth option called “let it ride.” If the stop condition already fired, you only have kill or park. Transfer requires a living incoming owner who replies in-thread.
Incoming owner repeats the process list. They run the inspection commands and compare PIDs with the card. Mismatch means kill first and reconstruct later from artifacts. They do not attach a debugger to a process they do not own.
Reviewer signs or vetoes. The reviewer checks data class, tool allowlist, and whether anyone is talking about production. A veto parks the card and kills the process. Silence from the reviewer is not approval; it is a missing signature.
Someone updates the wiki timestamp. The card is the source of truth, not the Slack thread that will scroll away. If the wiki is down, you kill the loop rather than extending it on memory.

Inspection commands you should actually run

Label these as a local rehearsal checklist, not as measured production telemetry. Run them on the shared host you control, and never against a machine you do not administer.

# Proposed inspection — run only on your rehearsal host
date -u
whoami
pwd
ps -eo pid,etime,user,cmd | awk 'NR==1 || /python|uvicorn|node|agent/'
ss -lptn 2>/dev/null | head
ls -lt ./artifacts/session-cards 2>/dev/null | head

If etime is already past the “must stop at” field, you do not investigate further for curiosity. You execute the kill command written on the card. Curiosity is how a “quick look” becomes another unowned overnight loop.

# Proposed kill — replace with the line stored on the wiki card
kill -TERM <PID>
sleep 2
ps -p <PID> || echo "process gone"
# if it still exists:
kill -KILL <PID>

Park means you persist artifacts and then kill anyway. A parked loop is a directory plus a card, not a sleeping process that might wake and keep calling tools.

Session card artifact (proposed Python)

The script below is a proposed helper, not a benchmarked service, and you should read it before running it. It refuses to start when required ownership fields are missing. That refusal is the entire point: the agent must not outrank the roster.

# proposed_session_card.py — example only, not production control plane
from __future__ import annotations

import json
from datetime import datetime, timezone
from pathlib import Path

REQUIRED = (
    "experiment_id",
    "hypothesis",
    "data_class",
    "host",
    "session_owner",
    "incoming_owner",
    "reviewer",
    "stop_condition",
    "kill_command",
    "decision",
)

ALLOWED_DECISIONS = {"kill", "park", "transfer"}
ALLOWED_DATA = {"public-sample", "synthetic"}


def build_card(payload: dict) -> dict:
    missing = [key for key in REQUIRED if not str(payload.get(key, "")).strip()]
    if missing:
        raise ValueError(f"refusing to start loop; missing fields: {missing}")
    if payload["decision"] not in ALLOWED_DECISIONS:
        raise ValueError("decision must be kill, park, or transfer")
    if payload["data_class"] not in ALLOWED_DATA:
        raise ValueError("customer or unknown data classes are not allowed on shared hosts")
    if payload["session_owner"] == payload["reviewer"] and payload["decision"] == "transfer":
        raise ValueError("transfer needs a reviewer who is not the current session owner")
    payload = dict(payload)
    payload["written_at_utc"] = datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%SZ")
    return payload


def write_card(payload: dict, directory: str = "./artifacts/session-cards") -> Path:
    card = build_card(payload)
    out_dir = Path(directory)
    out_dir.mkdir(parents=True, exist_ok=True)
    path = out_dir / f"{card['experiment_id']}.json"
    path.write_text(json.dumps(card, indent=2), encoding="utf-8")
    return path


if __name__ == "__main__":
    demo = {
        "experiment_id": "spike-2026-09-10-agent-loop",
        "hypothesis": "A tighter tool allowlist reduces retry storms overnight.",
        "data_class": "synthetic",
        "host": "shared-rehearsal",
        "session_owner": "alex",
        "incoming_owner": "sam",
        "reviewer": "riley",
        "stop_condition": "wall-clock 4h or 8 consecutive tool errors",
        "kill_command": "kill -TERM 12345",
        "decision": "park",
    }
    print(write_card(demo))

Wire your starter script so it calls build_card() before it launches the agent. If you cannot import this check, you also cannot claim you had a handoff. A README sentence is not an ownership control.

Decision table: kill, park, or transfer

Use this table on the wiki page so people stop inventing local folklore. When two rows could apply, choose the upper row. Upper rows prefer a dead process over an unexplained live one.

Condition	Decision	Who acts	What you must leave behind
Stop condition already hit, or PID is not on the card	kill	incoming owner	wiki note with timestamp
Incoming owner did not reply before you leave	park, then kill	outgoing owner	card plus artifact directory
Data class is unclear or tools expanded mid-loop	kill	reviewer or incoming	short incident note
Work is useful, next human is present, allowlist unchanged	transfer	both owners	updated card and PID
Anyone mentions production, customers, or real secrets	kill	reviewer	do not park on the shared host

Transfer is the narrow path. It requires a living incoming owner, a reviewer signature, and a stop condition that still has budget. Everything else is park or kill. “The agent is almost done” is not a row in the table.

Where a free model tier participates

You need a cheap rehearsal lane so this SOP gets used before anyone touches paid production routing. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode is an open project that currently states it offers free model access, a stated ten-million-token pool, and a free server option for that kind of rehearsal.

Use that lane only for synthetic or public-sample prompts that match the card’s data class. Put the session card in git or the wiki, not in the model prompt, so ownership survives even if the chat transcript is noisy. If the free server is shared, the four roles matter more, not less, because collision cost is social as well as technical.

Do not treat those free-tier statements as a capacity plan, a latency promise, or a permanent quota. This playbook does not measure throughput and does not name models. If the rehearsal host disappears, your artifacts and wiki page should still explain what you were testing.

Limitations and who should not use this

This SOP does not replace access control, secrets management, or a real orchestrator. It will not save you if the agent can reach customer data, production credentials, or billing accounts. Shared free hosts are the wrong place for regulated workloads, medical text, or anything you would not paste into a public ticket.

Skip this approach when you are a solo hobbyist with a laptop that nobody else shares. Skip it when your company already forbids external model providers or shared servers. Skip it when the loop must stay up for customers; that workload needs paging and budgets, not a one-page wiki card.

Also skip overnight loops when you cannot write an exact kill command. If you cannot kill it, you do not own it, and the agent is only borrowing your reputation. Park the idea, commit the prompt, and start again when a human is actually watching.

Keep the roster louder than the agent

Overnight agent failures are usually social: no incoming owner, no stop rule, and a process that outlived the chat. Fill the four names, generate the session card, and make kill the default when the card and the host disagree. If you want a shared rehearsal place to practice the handoff itself, try MonkeyCode’s stated free model access and free server option, then see whether Monday still starts with a named owner.

Name an Assumption Owner: A Four-Role Wiki Handoff for Shared AI Labs

Alex Zhu — Wed, 09 Sep 2026 15:31:36 +0000

You open Slack on Monday and find a half-finished agent demo still bound to a shared host. Nobody can say which prompt the agent used, which tool it called, or who may restart the box. The weekend volunteer already hopped onto another ticket, and the channel holds only a screenshot of a green check. You need a handoff that names owners before the next person types a destructive command.

This page is a paste-ready SOP for that Monday, not another glossary of agent slang. You will assign four role cards, freeze unspoken assumptions, and run a one-page wiki checklist before anyone touches the shared lab. The artifact is deliberately boring: YAML role cards, a markdown run, and a small Python gate that fails when the handoff is incomplete. If you strip every product name from this workflow, the checklist should still stop a confused restart.

The Monday failure this playbook targets

Shared AI labs fail in a social way long before they fail in a numeric way. Someone pastes a clever agent loop into a free host, the loop quietly fills missing specs, and the next person treats those guesses as policy. You then inherit a running process, an undocumented tool allowlist, and a chat log that never recorded who approved the guess. Role cards exist so the guess has a human owner instead of a screenshot.

You should use this SOP when two or more people share a coding agent, a prompt file, and a long-lived server. You should not use it as a substitute for real access control, secrets management, or production change review. The goal is a wiki page that a tired teammate can execute without rereading the weekend thread.

Four role cards you pin above the runbook

Give every shared lab four named humans, even when the same person wears two cards for a week. Write the names in the wiki, not in a private message that disappears after the sprint. Rotate on a calendar you already use, because a clever new rotation tool will itself need a handoff.

Assumption Owner — the person who must write down every fact the agent invented, including paths, IDs, and default models.
Server Steward — the person who may start, stop, or reprovision the shared host, and who posts the new endpoint.
Prompt Librarian — the person who versions the system prompt, tool list, and any MCP-style connector notes in git.
Handoff Receiver — the person who will be awake at nine, who must reject the lab if any required field is still TBD.

You keep the cards short so people actually wear them. You do not invent a fifth coordinator unless two teams share the same host and already collide. If a role is vacant, you treat the lab as frozen, which is safer than letting the agent keep assuming.

One-page wiki run you can paste today

Copy the block below into your team wiki and fill the backticks during the last thirty minutes of a spike. Speak in commands and file paths, not in vibes about how well the agent seemed to behave. The receiver should be able to replay the lab from this page without opening the original chat.

# Shared AI lab handoff
Date (UTC): YYYY-MM-DD
Spike title:
Repo + commit:
Prompt path:
Tool/MCP list path:
Host name / URL:
Process manager (systemd, docker, other):

## Role cards
- Assumption Owner:
- Server Steward:
- Prompt Librarian:
- Handoff Receiver:

## Assumptions the agent made (must not be empty)
- [ ] Invented file path or module name:
- [ ] Invented environment variable:
- [ ] Invented “safe default” in a tool call:
- [ ] Invented user, tenant, or dataset identity:

## Freeze / thaw
- Freeze command:
- Thaw command:
- Who may thaw:
- Secrets location (not the secret itself):

## Monday first hour
1. Receiver reads assumptions aloud.
2. Steward confirms the process is stopped or pinned.
3. Librarian diffs prompt and tool list against main.
4. Owner files tickets for every remaining guess.
5. Receiver signs the wiki page or rejects the lab.

You treat an empty assumption list as a failed handoff, not as proof the agent was careful. Agents hide guesses inside default arguments, and those guesses travel farther than a chatty system prompt. If you cannot name a guess, you probably have not looked at the tool trace yet.

Numbered run for the last half hour of a spike

Follow the steps in order even when the demo looks healthy. A green check on a shared host is not a transfer of ownership. You are buying a clean Monday, not extra minutes of model output.

Stop generating. Ask the agent for a tool trace and save it beside the prompt file.
Fill the four role cards. If a name is missing, freeze the host and end the spike.
Walk the trace with the Assumption Owner and write every invented default as a bullet.
Ask the Prompt Librarian to commit prompt, tools, and the trace with the same message.
Ask the Server Steward to pin or stop the process and paste the exact freeze command.
Ping the Handoff Receiver with the wiki link only, not a stack of screenshots.
Receiver replies ACCEPT or REJECT on the wiki page before logging off.

You should keep the freeze command copy-pasteable. A steward who must reconstruct flags from memory will reconstruct them wrong. Put the command in the wiki even if it looks too simple to document.

Artifact: role file plus a gate that fails incomplete handoffs

Store the living names in git so the wiki and the repo cannot drift for a week. The YAML below is a template, not evidence from a particular company, so label it as a proposal you will edit. Keep secrets out of this file; it only names people and paths.

# handoff.yaml — proposal for a shared AI lab
spike: "weekend-agent-demo"
repo: "your-org/your-lab"
commit: "REPLACE_ME"
prompt_path: "prompts/system.md"
tools_path: "prompts/tools.json"
host: "shared-lab.example.internal"
roles:
  assumption_owner: "REPLACE_ME"
  server_steward: "REPLACE_ME"
  prompt_librarian: "REPLACE_ME"
  handoff_receiver: "REPLACE_ME"
assumptions:
  - "Agent created app/router_v2.py without a ticket."
  - "Agent set REQUESTS_TIMEOUT=3 as a silent default."
freeze_command: "docker compose -f lab.yml stop agent"
thaw_command: "docker compose -f lab.yml up -d agent"
who_may_thaw: "server_steward"
receiver_decision: "PENDING"  # ACCEPT | REJECT | PENDING

Save the checker next to the YAML and run it in the same working tree. The script only validates structure and forbidden placeholders; it does not claim to understand your agent. You still need a human to judge whether an assumption is real.

#!/usr/bin/env python3
"""Fail a shared-lab handoff when role cards or assumptions are still blank."""

from pathlib import Path
import sys
import yaml

REQUIRED_ROLES = (
    "assumption_owner",
    "server_steward",
    "prompt_librarian",
    "handoff_receiver",
)
BANNED = {"", "REPLACE_ME", "TBD", "TODO", None}


def main(path: str) -> int:
    data = yaml.safe_load(Path(path).read_text())
    errors = []

    roles = data.get("roles") or {}
    for role in REQUIRED_ROLES:
        if roles.get(role) in BANNED:
            errors.append(f"role {role} is unnamed")

    assumptions = data.get("assumptions") or []
    if not assumptions:
        errors.append("assumptions list is empty")
    for item in assumptions:
        if item in BANNED:
            errors.append("assumption placeholder still present")

    for key in ("freeze_command", "thaw_command", "prompt_path", "tools_path"):
        if data.get(key) in BANNED:
            errors.append(f"{key} is unset")

    decision = data.get("receiver_decision")
    if decision not in {"ACCEPT", "REJECT", "PENDING"}:
        errors.append("receiver_decision must be ACCEPT, REJECT, or PENDING")

    if errors:
        print("HANDOFF INCOMPLETE")
        for err in errors:
            print(f"- {err}")
        return 1

    print("HANDOFF STRUCTURE OK — receiver still must read the wiki")
    return 0


if __name__ == "__main__":
    sys.exit(main(sys.argv[1] if len(sys.argv) > 1 else "handoff.yaml"))

Run it locally before you ping the receiver. Keep the command in the same wiki page as the role cards so nobody hunts through chat history.

python3 -m pip install pyyaml
python3 check_handoff.py handoff.yaml
echo $?  # 0 means structure only; humans still accept or reject

If the checker exits nonzero, you do not thaw the host. A missing name is cheaper to fix on Sunday night than after someone restarts the wrong container. You can wire the script to a pre-push hook later; do not wait for CI philosophy before using it by hand.

Where a free shared lab fits, and where it does not

You can rehearse this SOP on any disposable host your team already shares. A dedicated free coding environment helps only when you want the roles to collide in a realistic way without burning a paid quota during practice. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode currently offers free model access and a free server option, which you can use as the shared lab while you learn the four-card handoff. Do not treat that option as an SLA, a capacity plan, or a promise about named models, hardware, or how long the tier lasts.

If you try the dry run there, still keep prompts, traces, and role YAML in your own git remote. A free server is a place to execute, not a place to store the only copy of who owned the last guess. When the practice spike ends, the Server Steward should freeze the process with the same command you documented, even if nobody is waiting on Monday.

Limitations, and who should skip this SOP

This playbook will annoy a solo developer who already owns every file and every reboot. It will also fail a regulated workload that needs ticketed change control, because a wiki page is not an audit log. You should skip it when the agent can reach production data, customer secrets, or networks you do not fully control.

The Python gate cannot see lies. An Assumption Owner can write a cheerful bullet that hides a worse default inside a tool schema. The Handoff Receiver still has to read the trace, not only the YAML keys. If your traces are truncated, you do not have a handoff; you have a story about a handoff.

Free shared hosts also disappear, throttle, or change behavior without a meeting. You should not put customer traffic, cron that must hit a wall clock, or irreversible migrations on that class of machine. Use the lab to practice ownership, then promote the same role cards onto whatever paid environment your team already trusts.

Close the loop on Tuesday, not in the retro two weeks later

On Tuesday, look at the accepted page and file one ticket per remaining assumption. Convert invented paths into real design notes, or delete the files the agent created without permission. Then rotate at least one role card so the same person is not forever the only adult in the lab.

You will know the SOP is working when a spike can end with REJECT and nobody takes it personally. A rejected lab is a successful handoff, because the next person refused to inherit a guess. Keep the page to one screen, keep the checker strict, and let the agent stay silent until a named human owns what it assumed.

A Staging-Gate Playbook for AI Spikes on Shared Free Hosts

Alex Zhu — Sun, 06 Sep 2026 20:53:54 +0000

You join the afternoon standup and someone demos a chatbot that already talks to staging data. Token cost looked like zero, so the spike used a free remote model without named owners. You ask who pages if the endpoint starts leaking customer fields, and the room goes quiet. That silence is the real incident, because promotion happened without a written gate on the wiki.

The failure you are actually debugging

A free-tier spike fails in a quieter way than a crashed process or a red deploy. The model answers quickly, the shared host stays up, and reviewers assume someone else classified the data. You later find prompt logs in a world-readable volume, plus an API token inside a notebook. None of those mistakes required advanced attackers, because they only required a missing promotion owner on the wiki.

Name five roles before anyone shares a URL

You should refuse a public demo until these names exist in the wiki, even if the prototype still runs on a laptop. The names can be placeholders, but they cannot be Slack group mentions that nobody reads. If a role is vacant, the gate fails closed, and the spike must stay on a private branch. You are not blocking creativity; you are blocking an implicit production contract that nobody signed.

1. Prototype owner

The owner is the person who can delete the spike on the same day it misbehaves. They keep the repository path, the inference endpoint, and the data class in one wiki row. If they go on leave, they hand the row to a named deputy before the next working day. You should not accept the intern who started it unless that intern can actually take the page.

2. Data steward

The steward says whether prompts, tools, and logs may leave the laptop for a free remote host. They classify the payload as public, internal, or restricted, and they write the class beside the endpoint. Restricted data stops the gate even when the model quality looks excellent in a demo. You ask them to sign the row, not to bless a vendor in the abstract.

3. Inference operator

The operator records where tokens actually go, including a free shared server if that is the current backend. They document failover: local stub, queued jobs, or a hard error, never a silent model swap. They also record how secrets are injected, because notebook paste is not an injection strategy. You treat this role as production work even while the invoice is still zero.

4. Promotion reviewer

The reviewer is not the person who wrote the spike, and they do not rubber-stamp a video recording. They run the checker script in this article and they read the wiki row against the repository. If the checker fails, they comment on the pull request instead of debating model quality in chat. You want a reviewer who can say no without writing a long manifesto in the thread.

5. On-call delegate

Someone must receive the first human message when the free host stalls or the prompt cache starts echoing secrets. That person needs a rollback command they can run, not a link to a long design document. If you cannot name them, you do not have a service; you have a group chat with extra latency. Write their working hours beside the rollback command so overnight pages have a realistic chance.

Handoffs happen on the wiki row, not in a private message after the demo. When the prototype owner changes, they update the row in the same pull request that transfers repository permissions. If the on-call delegate is away, the promotion reviewer blocks staging rather than borrowing a random engineer from another team. You should treat a missing handoff as a failed gate, not as a calendar problem to ignore.

Run this seven-step gate in order

Do not skip ahead to hosting just because the demo impressed a stakeholder in the hallway. Walk the steps in order, and keep the evidence on the wiki row instead of in screenshots. If a step has no artifact, the promotion reviewer stops the gate and leaves the spike private. You can still finish a small spike in one afternoon when the fields are honest and complete.

Step 1: Freeze the spike identity

You create a wiki row with a short name, a repository URL, and a single owning team. You refuse duplicate names like new-bot-final-2, because later handoffs cannot search slang titles in the wiki. You add the date the spike first left the laptop, even if that date is this morning. The row is the object you will promote, reject, or delete; chat threads are not objects.

Step 2: Classify every payload that can leave the process

You list prompts, retrieved chunks, tool arguments, and traces as separate rows, not as one fuzzy user-data blob. The steward marks each row public, internal, or restricted before any remote call is enabled. Restricted rows block free remote hosts, including shared servers that feel isolated during a hallway demo. If classification is unknown, you keep inference on the laptop and you do not share URLs.

Step 3: Inventory the inference path

You write the provider, the access mode, and whether the host is shared, dedicated, or local. You do not paste marketing pages into the wiki and then call that a complete inventory. If the path uses free model access, you say so in plain language beside the owner. You also note that free paths can change without a procurement ticket, so failover cannot be hope.

Step 4: Scan secrets as if the notebook were already public

You run a secret scanner on the repo, the env files, and any exported notebooks before reviewers judge model quality. You rotate anything that appeared in a prompt, because model logs are not a vault. You store replacements in the team secret manager and you reference the path from the wiki row. A screenshot of a green demo does not replace this scan, no matter who attended the hallway review.

Step 5: Declare failover in one sentence you could read at 2 a.m.

You write what the product does if the free host is slow, full, or gone. Allowed answers are fail closed, serve a local stub, or queue work for a named operator. Forbidden answers include silently switching models, retrying customer data against a new host, or paging everyone. You test the chosen path once with a killed endpoint, then you record the command you used.

Step 6: Run the checker in CI

You add the script below as a proposed gate job that fails the pull request when required fields are empty. You keep the job boring: it does not call a model and it does not scrape vendor status pages. Reviewers should be able to reproduce a failure with one command on their own laptop after cloning. If the job is skipped, the promotion decision stays blocked even when stakeholders are waiting in the channel.

Step 7: Record sandbox, staging, or blocked

You write one of those three words on the wiki row, plus the reviewer name and the date. Sandbox means named testers only, no customer identifiers, and a deletion date no later than two weeks. Staging means the five roles are filled, secrets are rotated, and failover was exercised once. Blocked means the spike stays private; you do not negotiate that word in a hallway.

Paste this one-page run into the wiki

Copy the block into your team wiki and replace the placeholders before the next demo. Keep it on one page so a reviewer can finish it during a single pull request. If the page grows past a screen, you are hiding vacant roles behind prose. The checker reads a YAML twin of this page, so keep the field names stable.

# AI spike staging gate

- spike_id:
- repo_url:
- owning_team:
- first_left_laptop:
- data_class: public | internal | restricted
- inference_mode: free_remote | self_hosted | vendor_paid
- inference_provider:
- failover: fail_closed | local_stub | queue_for_operator
- secret_scan_at:
- secret_manager_path:
- named_testers:
- delete_after:
- vendor_review_url: (required when restricted + staging)
- decision: sandbox | staging | blocked
- reviewer:
- reviewed_at:

## Roles
- prototype_owner:
- data_steward:
- inference_operator:
- promotion_reviewer:
- oncall_delegate:
- oncall_hours:
- rollback_command:

## Handoff
- previous_owner:
- new_owner:
- permissions_pr:
- reason:

## Evidence
- payload inventory link:
- failover test command:
- checker log:

Reproduce the checker on your laptop

The following checker is a proposed example that you should treat as unexecuted until you run it locally. It never calls a model, so a failure means the wiki row is incomplete rather than the vendor is down. You can drop the files into an empty directory and learn the gate without touching production data. If PyYAML is missing, install it in a virtualenv instead of adding it to a production image.

Create a local virtualenv first so the checker dependency never lands in a production image.

python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install pyyaml

Save the YAML map below as promotion.yaml beside the checker, using honest placeholders instead of empty strings.

spike_id: billing-faq-spike
repo_url: https://git.example.internal/app/billing-faq-spike
data_class: internal
inference_mode: free_remote
failover: fail_closed on timeout; local_stub for unauthenticated testers
secret_scan_at: "2026-09-07T10:00:00Z"
decision: sandbox
named_testers:
  - jordan
  - sam
delete_after: "2026-09-21"
roles:
  prototype_owner: jordan
  data_steward: data-governance
  inference_operator: platform-ai
  promotion_reviewer: sre-review
  oncall_delegate: sam

Run the checker once and confirm a passing row prints PROMOTION GATE PASSED with the spike identifier.

python3 check_promotion.py --file promotion.yaml

Delete the on-call name, run the same command again, and confirm the process exits nonzero.
Add the command as a CI step that fails the pull request when the wiki twin is incomplete.

#!/usr/bin/env python3
"""Proposed promotion-gate checker. Treat as unexecuted until you run it locally."""

from __future__ import annotations

import argparse
import sys
from pathlib import Path

try:
    import yaml
except ImportError:
    print("Install PyYAML: python3 -m pip install pyyaml", file=sys.stderr)
    sys.exit(2)

REQUIRED_ROLES = (
    "prototype_owner",
    "data_steward",
    "inference_operator",
    "promotion_reviewer",
    "oncall_delegate",
)
REQUIRED_FIELDS = (
    "spike_id",
    "repo_url",
    "data_class",
    "inference_mode",
    "failover",
    "secret_scan_at",
    "decision",
)
ALLOWED_DATA_CLASS = {"public", "internal", "restricted"}
ALLOWED_MODE = {"free_remote", "self_hosted", "vendor_paid"}
ALLOWED_DECISION = {"sandbox", "staging", "blocked"}
PLACEHOLDERS = {"tbd", "n/a", "ai", "intern-rotating", "todo"}


def load_row(path: Path) -> dict:
    data = yaml.safe_load(path.read_text(encoding="utf-8"))
    if not isinstance(data, dict):
        raise ValueError("promotion file must be a mapping")
    return data


def problems(row: dict) -> list[str]:
    issues: list[str] = []
    for key in REQUIRED_FIELDS:
        if not row.get(key):
            issues.append(f"missing field: {key}")

    roles = row.get("roles") or {}
    for key in REQUIRED_ROLES:
        value = roles.get(key) if isinstance(roles, dict) else None
        label = str(value or "").strip().lower()
        if not label or label in PLACEHOLDERS:
            issues.append(f"role vacant or placeholder: {key}")

    data_class = str(row.get("data_class", "")).lower()
    mode = str(row.get("inference_mode", ""))
    decision = str(row.get("decision", ""))

    if data_class and data_class not in ALLOWED_DATA_CLASS:
        issues.append("data_class must be public, internal, or restricted")
    if mode and mode not in ALLOWED_MODE:
        issues.append("inference_mode must be free_remote, self_hosted, or vendor_paid")
    if decision and decision not in ALLOWED_DECISION:
        issues.append("decision must be sandbox, staging, or blocked")
    if data_class == "restricted" and mode == "free_remote":
        issues.append("restricted data cannot use free_remote inference")
    if decision == "staging" and data_class == "restricted" and not row.get("vendor_review_url"):
        issues.append("missing field: vendor_review_url")

    failover = str(row.get("failover", "")).lower()
    forbidden = ("silent swap", "switch model", "page everyone", "hope")
    if any(token in failover for token in forbidden):
        issues.append("failover is too vague or forbidden")

    testers = row.get("named_testers") or []
    if decision == "sandbox" and not testers:
        issues.append("sandbox decision requires named_testers")
    if decision == "sandbox" and not row.get("delete_after"):
        issues.append("sandbox decision requires delete_after")
    return issues


def main() -> int:
    parser = argparse.ArgumentParser(
        description="Fail closed when promotion wiki fields are empty"
    )
    parser.add_argument("--file", default="promotion.yaml")
    args = parser.parse_args()
    path = Path(args.file)
    if not path.exists():
        print(f"missing {path}", file=sys.stderr)
        return 1
    try:
        row = load_row(path)
    except Exception as exc:
        print(f"invalid yaml: {exc}", file=sys.stderr)
        return 1
    issues = problems(row)
    if issues:
        print("PROMOTION GATE FAILED")
        for item in issues:
            print(f"- {item}")
        return 1
    print("PROMOTION GATE PASSED")
    print(f"decision={row.get('decision')} spike_id={row.get('spike_id')}")
    return 0


if __name__ == "__main__":
    sys.exit(main())

A passing run should print the decision and spike id, then exit zero. A missing on-call name should print PROMOTION GATE FAILED and return status 1. You can wire that status into GitHub Actions, GitLab CI, or a pre-push hook without teaching the job anything about models. Keep the YAML in the same pull request as the spike so reviewers never hunt through chat for owners.

Where a free model host fits this gate

Some teams run the sandbox step against MonkeyCode, which offers free model access and a free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Treat that pair as a convenience for spikes, not as a silent production backend with implied uptime. If your sandbox already points at that free server, fill the wiki row first, then decide whether the spike still deserves a URL.

Limitations

This playbook will not make a free shared host into a regulated production region with an implicit uptime contract. It will not rank models, estimate token burn, or prove that a complimentary server will still exist next quarter. You should not send health data, payment data, or government identifiers through any free remote path just because the wiki row is complete. The gate only records decisions; it does not encrypt payloads or replace a real vendor review.

Who should skip this playbook

Skip this SOP if you are a solo developer whose process never leaves localhost and never touches shared credentials. Skip it if your platform team already blocks unknown inference hosts in CI with a stronger policy engine. Skip it if you hoped a free server would become the production backend without a procurement conversation. In those cases the wiki page becomes theater, and theater is usually how shadow production starts.

You do not need a larger platform team to stop free-tier spikes from becoming shadow production. You need five names, one wiki row, and a checker job that fails closed on missing fields. If a demo cannot survive that gate, it was not ready for staging data, however fluent the model sounded. Keep the page short enough that a tired reviewer will actually read it before the next standup.

Freeze Agent Topology Guesses With a One-Page Wiki SOP

Alex Zhu — Sat, 05 Sep 2026 19:23:25 +0000

The Monday queue that never existed

You ship a Friday agent patch that only needed a retry helper, then staging dies on Monday. The diff added a worker process, a queue name, and three environment keys nobody provisioned. Your teammate trusted the model because the code compiled and the unit tests used mocks. This playbook treats those invented topology guesses as review items, not as clever extras.

Cheap iteration makes the problem worse, because another agent pass can invent a cache, a sidecar, and a hostname before lunch. You do not need a new architecture committee for every helper function that lands in a brownfield service. You need a freeze rule, named roles, and a checker that fails the build when guesses leak into compose files. The rest of this article is a paste-ready SOP plus a small Python artifact you can drop into CI.

Why agent guesses survive code review

Most pull request templates ask for tests, screenshots, and a rollback note, then stay silent about new runtime dependencies. They rarely ask whether Redis, Kafka, or a second Postgres showed up without an owner. Reviewers skim Python and miss YAML, especially when the model formatted the YAML cleanly and the unit tests never boot the stack. A remote drafting loop makes that cycle faster, which stays useful until the guesses compound across two or three small patches.

You should assume the agent will fill every gap in your brownfield repo when the prompt says the tests must pass. Missing helm values become reasonable looking defaults that nobody in ops has ever seen. Missing base URLs become localhost plus a lucky port that collides with a laptop sidecar. Missing secrets become placeholder names that later get copied into a real shell profile during a late incident. The SOP below forces those fills into a ledger before merge, so the guess has a human owner.

Roles you can name in the wiki

Keep four roles on a single page so the handoff does not depend on who happens to be online. Write the names beside the freeze steps, not in a private doc that only the original author can find. If a role is empty during a holiday week, the merge waits rather than inventing a substitute in chat. That rule sounds harsh until you remember the queue that never existed.

Change Author ran the agent, owns the diff, and must list every new runtime dependency the model introduced.
Assumption Reviewer is not the author and only signs the ledger, without redesigning the feature under review.
Runtime Owner confirms staging and production actually provide those hosts, queues, buckets, and credentials.
Wiki Steward rejects template drift and restores the one-page run when people start pasting novels into the freeze page.

If your team is three people, the reviewer and runtime owner can be the same human, but they cannot be the author. Write that constraint in the wiki so Friday shortcuts do not quietly rewrite the rule when chat is empty. Rotate the reviewer weekly if the same pair always ships together, because familiarity is how invented hostnames survive.

The one-page run (paste this)

Copy the following numbered run into your team wiki, and keep the whole contract on one screen so people actually follow it during review. Do not attach architecture essays, vendor comparisons, or a history of past outages on this page. Those belong one click away, linked from the steward section, so the freeze stays usable under time pressure.

Freeze the session. Stop the agent before a second "just fix CI" turn, then export the last prompt and the file list the model touched.
Diff for topology, not only for logic. Search the branch for compose services, Helm charts, Terraform, GitHub Actions service containers, and new environment keys.
Write one ledger row per guess. A guess is any host, port, queue, bucket, model endpoint, or secret name that the repo did not already document.
Run the checker locally. The script below must exit non-zero when an undocumented service or environment key appears in the branch.
Handoff to the Assumption Reviewer. They only confirm the ledger is complete for this diff, and they do not redesign the feature.
Runtime Owner marks each row as exists, will-provision, or rejected, using the decision table later in this page.
Merge only with zero unreviewed rows. If CI is red because the checker failed, treat that redness as a process success rather than a flake.

That seven-step contract is the entire operational freeze, and it should stay short enough to read during a standup. Longer essays belong in architecture docs, not in the freeze page that reviewers open while the agent is still warm. If someone needs a novel to merge a retry helper, the page has already failed its job.

Artifact: an assumption ledger and a failing checker

Store a known-good allowlist next to the SOP, and keep the file boring on purpose so you will actually maintain it after the first week. Proposed example only: this YAML is a starting template, not a description of your production estate. Replace the names with services you already run, then commit the file before you turn the checker on.

# config/topology_allowlist.yaml
services:
  - api
  - worker
  - postgres
env_keys:
  - DATABASE_URL
  - API_TOKEN
  - LOG_LEVEL
hostnames:
  - api.internal
  - postgres.internal

Treat the next snippet as a proposed checker you must adapt, not as a battle-tested product that understands every manifest. You should extend the filename globs to match Helm, Terraform, and whatever else your agents are allowed to touch. The heuristics are intentionally narrow so a first run fails on invented queues instead of on every constant in the repo.

# tools/check_agent_assumptions.py
"""Fail CI when agent diffs invent services, env keys, or hostnames."""

from __future__ import annotations

import re
import sys
from pathlib import Path

import yaml

ROOT = Path(__file__).resolve().parents[1]
ALLOW = yaml.safe_load((ROOT / "config" / "topology_allowlist.yaml").read_text())
SERVICE_RE = re.compile(r"^\s{2}([a-zA-Z0-9_-]+):\s*$")
ENV_RE = re.compile(r"\b([A-Z][A-Z0-9_]{2,})\b")
HOST_RE = re.compile(r"\b([a-z0-9-]+(?:\.[a-z0-9-]+)+)\b")

SCAN_GLOBS = [
    "docker-compose*.yml",
    "compose*.yaml",
    ".env.example",
    "**/*.py",
    ".github/workflows/*.yml",
]


def iter_files() -> list[Path]:
    files: list[Path] = []
    for glob in SCAN_GLOBS:
        files.extend(ROOT.glob(glob))
    return [p for p in files if p.is_file()]


def services_from_compose(text: str) -> set[str]:
    names: set[str] = set()
    in_services = False
    for line in text.splitlines():
        if line.startswith("services:"):
            in_services = True
            continue
        if in_services and line and not line.startswith(" "):
            in_services = False
        if in_services:
            match = SERVICE_RE.match(line)
            if match:
                names.add(match.group(1))
    return names


def main() -> int:
    allowed_services = set(ALLOW["services"])
    allowed_env = set(ALLOW["env_keys"])
    allowed_hosts = set(ALLOW["hostnames"])
    invented: list[str] = []

    for path in iter_files():
        text = path.read_text(encoding="utf-8", errors="ignore")
        rel = path.relative_to(ROOT)
        if path.name.startswith("docker-compose") or path.name.startswith("compose"):
            for name in services_from_compose(text) - allowed_services:
                invented.append(f"{rel}: service `{name}` is not in the allowlist")
        for key in set(ENV_RE.findall(text)) - allowed_env:
            if key.endswith("_URL") or key.endswith("_TOKEN") or key.endswith("_HOST"):
                invented.append(f"{rel}: env key `{key}` is not in the allowlist")
        if path.suffix == ".py" or "workflows" in str(rel):
            for host in set(HOST_RE.findall(text)) - allowed_hosts:
                if host.endswith(".internal") or host.endswith(".local"):
                    invented.append(f"{rel}: hostname `{host}` is not in the allowlist")

    if invented:
        print("Assumption freeze failed. File ledger rows before merge:")
        for item in sorted(set(invented)):
            print(f"- {item}")
        return 1
    print("Assumption freeze passed.")
    return 0


if __name__ == "__main__":
    sys.exit(main())

Run the checker after every agent session, including personal branches, rather than waiting for the main branch build to surprise you. Install the YAML parser in the same environment your CI already uses for lint, so you do not create a second Python toolchain. If the command fails, freeze the agent before you ask it to silence the output.

python -m pip install pyyaml
python tools/check_agent_assumptions.py

Pair the checker with a ledger the reviewer actually signs, and keep that table in the pull request body or in docs/assumption-ledger.md so the handoff is visible. Proposed example only: copy the header, then add one row per guess instead of writing a paragraph. Empty decisions mean the branch is not mergeable, even when the feature tests are green.

| ID | Guess | File | Author claim | Runtime owner | Decision |
| --- | --- | --- | --- | --- | --- |
| A-14 | `jobs` Redis service | docker-compose.yml | Needed for retries | Unreviewed | unreviewed |

Where a free remote drafting host belongs

You can run the agent that drafts the helper, and the checker that polices it, on separate machines without mixing their jobs. The checker should stay local or in CI so it does not depend on a model remaining available during an outage. The agent can live on a remote box if your laptop is already full of language servers, browsers, and half-finished containers. Keep that split explicit in the wiki so people do not skip the checker when the remote session is convenient.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. If your team already needs a remote place to run those agent sessions, consider a dedicated drafting host. MonkeyCode's free model access and free server option can host that loop while CI keeps the freeze checker. That split matters because generation can be cheap and remote, but topology truth stays in your allowlist and in the Runtime Owner's marks. Skip any vendor if you cannot point the agent at a private clone without copying production secrets into the prompt.

Do not paste credentials into the remote session, even when the box is convenient and the models are free to call. Point the agent at redacted compose files and .env.example only, then let humans fill real values in the secret store. If the model proposes a secret name, add a ledger row instead of trying that name against staging just to see. A freeze that leaks credentials is worse than a missing retry helper.

Decision table for the Runtime Owner

Use this table when a ledger row is not an obvious reject, and paste it under the one-page run so Slack threads do not become the real process. The author fills the guess type, and the Runtime Owner fills the two existence columns from actual staging and production, not from the agent's story. If either column is unknown, the decision is unreviewed until someone logs into the environment and looks.

Guess type	Exists in staging?	Exists in prod?	Decision	Handoff
New compose service	No	No	rejected unless a provision ticket exists	Author deletes the service from the diff
New env key	Yes	Yes	exists	Reviewer signs the ledger
New env key	Yes	No	will-provision	Runtime owner files an infra ticket
New hostname	No	No	rejected	Author must use an allowlisted name
New queue or bucket	Partial	No	will-provision	Do not merge until the ticket has an owner

Keep rejected rows in the ledger for a week so the next agent session does not rediscover the same queue. The Wiki Steward can archive them after the allowlist and the docs match. Do not delete evidence of a guess that almost shipped, because that is how the freeze teaches new authors.

Limitations, and who should not use this

The checker is a heuristic, not an architecture oracle, and it will miss a Kubernetes manifest you forgot to glob. It will also nag you about test fixtures that mention EXAMPLE_TOKEN, which is noisy but cheaper than a Monday outage. A human still has to read the ledger, because a hostname regex cannot tell a documentation example from a new dependency. This SOP does not replace threat modeling, capacity planning, or a change-advisory board in a regulated environment.

You should not use this approach if you are a solo hobbyist with no shared wiki, because the roles collapse into one person who will skip the freeze. You should also skip it for throwaway spikes that never leave a personal branch and never touch shared staging. Do not point a remote agent at production kubeconfigs, customer dumps, or live tokens, even when the server is free to use. If your topology lives only in someone's head, write the allowlist first; otherwise the checker has nothing honest to compare.

Teams that already generate large refactors with agents will feel friction for a week, and that friction is the point of the freeze. After the allowlist matches reality, most helper patches pass the checker in seconds, and only the invented queue still fails. If every patch fails, your allowlist is incomplete, not your engineers. Fix the file with the Runtime Owner before you disable the job.

Keep the wiki page short on purpose

When the SOP grows past one screen, people will ignore it and ask the agent to just make CI green. Put examples in a second page, and keep the freeze page limited to roles, the seven steps, the decision table, and a link to the checker. Review the allowlist when you actually provision a service, not on a calendar ritual that nobody attends. The steward's job is deletion as much as it is addition.

If you adapt this playbook, change the globs before you congratulate yourselves on a green pipeline. A checker that never sees Helm charts will happily bless an agent that invented three new releases. Treat that miss as a process bug, file it against the Wiki Steward, and keep the Monday queue in the story so new hires understand why the freeze exists.

Silent Defaults Are Incidents: A Shared AI Session Playbook

Alex Zhu — Fri, 04 Sep 2026 17:11:35 +0000

You walk into Monday stand-up and the on-call engineer is holding a stack trace nobody recognizes. Redis appears in the traceback, yet last week's architecture review never mentioned a cache layer at all. Friday's agent session invented that cache, a new environment variable, and a retry policy, then the author closed the laptop. You now own a production-shaped failure that never passed through an explicit human decision.

Cheap, always-on coding sessions make this pattern ordinary rather than rare. The agent keeps choosing defaults so the next person inherits architecture without inheriting the reasons. This playbook treats those silent defaults as incidents you log, hand off, and close before anyone else touches the branch.

What you are actually handing off

You are not handing off a chat transcript, a prompt file, or a pile of generated diffs. You are handing off every unstated choice the agent made about runtime, data, and failure behavior. If the next engineer cannot replay those choices from a one-page wiki entry, the session is still open, even when the editor is idle.

Name four roles before the next shared session starts, and keep the names boring on purpose. Session Owner starts and ends the run, and remains reachable until the assumption log is merged. Assumption Scribe writes the log in the same change as the code, not in a later cleanup pull request. Quota Steward watches shared model access and the shared server so two people do not collide. Incoming Owner is the next human who may ship, revert, or page on the result.

Those roles can collapse onto two people on a small team, but they cannot collapse onto the agent. The agent may draft the log; a named human still accepts it.

Classify the defaults before you classify the code

Walk every session through four buckets so the wiki page stays short enough to read during a page. Environment defaults cover interpreters, containers, ports, and working directories the agent assumed were already true. Dependency defaults cover libraries, datastores, queues, and SaaS calls that were not on the team's allowed list. Data defaults cover fixtures, seed files, PII handling, and retention the agent invented to make a test pass. Security defaults cover secrets, authn, authz, and network exposure that appeared because the happy path needed them.

You do not need a perfect taxonomy on day one. You need a rule that any default outside the current README is written down before the Session Owner logs off. If the scribe cannot fit the default into one of the four buckets, treat it as security until a human says otherwise.

A numbered run you can execute the same day

Create a session branch and a sibling file named assumption-log.yaml in the same directory as the change. Refuse to start the agent until that file exists with an owner, a scribe, and an expiry time in hours, not in vibes.
Paste the allowed stack into the session prompt as constraints, not as suggestions. State the language, the datastore, the queue, and the secret store the team already runs, and tell the agent that new infrastructure is a question, not a default.
After every agent pause, have the scribe append one record per new default, including the bucket, the file that now depends on it, and whether production already has that dependency. Do not wait for a "final" summary, because final summaries omit the boring choices.
Run the validator below before you push. A missing owner, an empty bucket, or an undeclared production impact should fail the same way a missing test fails.
Hand the Incoming Owner a four-line wiki note: session link or branch name, log path, quota steward, and the single question they must answer before merge. If they cannot answer it from the log, they bounce the session instead of guessing.
Close the session only after the log is in the same commit as the code, the wiki note is saved, and the Quota Steward records that the shared server is idle. An unclosed session is an open incident with a friendly name.

Artifact: a log schema and a validator you can paste

Keep the log boring and machine-checkable. Humans skim it; CI rejects it.

# assumption-log.yaml
session:
  id: "2026-09-05-billing-retry"
  owner: "alex.zhu"
  scribe: "sam.lee"
  quota_steward: "riley.nguyen"
  incoming_owner: "oncall-secondary"
  expires_at: "2026-09-05T22:00:00Z"
  shared_runtime: "team-free-server"
assumptions:
  - id: A1
    bucket: dependency
    default: "Introduced a local Redis for idempotent billing retries"
    evidence: "app/billing/retry.py"
    already_in_prod: false
    decision: "reject-or-rfc"
    reviewer: "incoming_owner"
  - id: A2
    bucket: environment
    default: "Assumed REDIS_URL is present in every process"
    evidence: "deploy/env.example"
    already_in_prod: false
    decision: "document-then-gate"
    reviewer: "session_owner"

# validate_assumption_log.py
from __future__ import annotations

import sys
from pathlib import Path

try:
    import yaml
except ImportError:
    sys.stderr.write("Install pyyaml before running this validator.\n")
    sys.exit: 2

REQUIRED_SESSION = {
    "id", "owner", "scribe", "quota_steward",
    "incoming_owner", "expires_at", "shared_runtime",
}
REQUIRED_ITEM = {
    "id", "bucket", "default", "evidence",
    "already_in_prod", "decision", "reviewer",
}
BUCKETS = {"environment", "dependency", "data", "security"}
DECISIONS = {"accept", "document-then-gate", "reject-or-rfc"}


def fail(message: str) -> None:
    sys.stderr.write(message + "\n")
    sys.exit(1)


def main(path: Path) -> None:
    payload = yaml.safe_load(path.read_text())
    session = payload.get("session") or {}
    missing = REQUIRED_SESSION - set(session)
    if missing:
        fail(f"session missing fields: {sorted(missing)}")

    rows = payload.get("assumptions") or []
    if not rows:
        fail("assumption log has zero records; empty means unreviewed defaults")

    for row in rows:
        missing_item = REQUIRED_ITEM - set(row)
        if missing_item:
            fail(f"{row.get('id')}: missing {sorted(missing_item)}")
        if row["bucket"] not in BUCKETS:
            fail(f"{row['id']}: unknown bucket {row['bucket']}")
        if row["decision"] not in DECISIONS:
            fail(f"{row['id']}: unknown decision {row['decision']}")
        if row["already_in_prod"] is False and row["decision"] == "accept":
            fail(f"{row['id']}: new default cannot be accepted without a gate")
        evidence = Path(row["evidence"])
        if not evidence.exists():
            fail(f"{row['id']}: evidence path does not exist: {evidence}")

    print(f"ok: {len(rows)} assumption(s) reviewed for {session['id']}")


if __name__ == "__main__":
    target = Path(sys.argv[1] if len(sys.argv) > 1 else "assumption-log.yaml")
    main(target)

python -m pip install pyyaml
python validate_assumption_log.py assumption-log.yaml

Wire the same command into the pre-push hook or the cheapest CI job you already run. The point is not ceremony. The point is that a silent Redis cannot ride along with a one-line retry fix.

Decision table for the Incoming Owner

Log signal	Already in prod?	What you do next	Merge?
New datastore, queue, or cache	No	Open an RFC or reject the default	No
New env var for an existing service	Yes	Document it, then add a boot-time check	After the check lands
New fixture that contains realistic personal data	Either	Delete the fixture and replace with synthetic rows	No
New network listener or public route	No	Treat as a security review, not a style review	No
Retry, timeout, or backoff the README already states	Yes	Keep the log row, skip extra process	Yes
Agent "helpfully" pinned a new major version	No	Revert the pin and ask the Session Owner	No

Read the table top to bottom during handoff, not after the deploy. If two rows apply, take the stricter one and leave a note for the Quota Steward.

Where a shared free runtime fits

Teams reach for a shared coding runtime because laptops differ and weekend work still happens. That is exactly when silent defaults spread, because the Session Owner is tired and the Incoming Owner is not in the room. You want one place the agent can run, and one place the log can live, without turning the weekend into a shadow architecture review.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode is one option that currently offers free model access, with an operator-stated allowance of 10 million tokens, plus a free server option you can use as the shared runtime named in the log. Use those only if they already match how your team handles code leaving the laptop; the playbook still works if you point shared_runtime at a machine you already operate.

The Quota Steward should record who is on the shared server, when the session expires, and whether another engineer may start a second session. None of that requires a vendor. It requires a named human who will say no when two agents would otherwise invent two caches.

Wiki page you can paste without editing the prose

# Shared AI session run (assumption log)

Roles this week
- Session Owner:
- Assumption Scribe:
- Quota Steward:
- Incoming Owner:

Before start
- [ ] Branch created
- [ ] assumption-log.yaml created with expiry
- [ ] Allowed stack pasted into the session constraints
- [ ] Shared runtime reserved on the steward's note

During session
- [ ] Every new default gets a row before the next prompt
- [ ] Evidence path points at a real file
- [ ] New infrastructure is reject-or-rfc, never accept

Before handoff
- [ ] python validate_assumption_log.py assumption-log.yaml
- [ ] Incoming Owner can answer: what will page us?
- [ ] Wiki note updated with branch, log path, steward
- [ ] Shared runtime marked idle

Print that checklist into the team wiki as a literal page, not as a link to this article. Links rot; the four roles should still be fillable during a page.

Limitations, and who should skip this

This playbook assumes you already have a wiki, a branch-based workflow, and at least two humans who can disagree in writing. Solo prototypes, classroom exercises, and throwaway spikes do not need a steward, and the validator will only slow you down. Regulated environments that cannot send source or logs to a remote model should keep the same roles and schema, then run the agent only on an approved runtime, or not at all.

The validator cannot see defaults that never touched the working tree, such as a secret pasted into a web UI. It also cannot judge whether Redis was a good idea; it can only refuse an undiscussed Redis. If your team ships generated code without review, an assumption log becomes theater, and you should fix review first.

Do not treat free model access or a free server as a durability guarantee, a performance claim, or a replacement for your own staging. Availability, quotas, and hardware change, and this article does not measure them. If the session produces a default you cannot explain in one sentence, revert the default before you argue about the tool that suggested it.

When the next agent invents a cache at 4 p.m. on Friday, you already know the owner, the scribe, and the question the Incoming Owner must answer. That is the whole playbook. If you need a shared place to run those sessions, you can try MonkeyCode's free models and free server, or you can point the same log at the runtime you already trust.

Free AI Tiers Are a Hypothesis: Auditing MonkeyCode's 10M Tokens and Free Server

Alex Zhu — Fri, 04 Sep 2026 11:09:46 +0000

Picture this: you find a project that offers ten million free tokens and a server that costs nothing, so you spend a weekend building a demo on top of it. The demo works, the README looks confident, and then the quota semantics turn out to be different from what you assumed, or the cold start turns your webhook into a two-second pause. The problem was never the free tier; the problem was that you treated a marketing claim as a measured fact.

Here is my position: a free tier is a trial, not a gift. The numbers in a README deserve the same skepticism you would give a vendor benchmark, which means you should run a small, cheap experiment before you build anything on top of them. This article walks through the acceptance test I recommend for any free AI stack, and it uses MonkeyCode's current free tier — ten million tokens plus a free server option — as the concrete case under examination. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Why the numbers are not the point

Token quotas and server specs are easy to print and hard to verify, and the difference usually hides in the details. A quota can be granted per day, per month, or per model family, and each interpretation changes the shape of your architecture. A free server can cold-start in two seconds or twenty, depending on the scheduler, and rate limits are often documented in a table but only enforced in a way you notice under load. None of this means you should avoid free tiers; it means you should audit them before you commit, because a limitation you measured is a constraint you can design around.

The acceptance test

The script below is a template, not a benchmark: you fill in your endpoint, your model name, and your token, and it answers four questions. Can the tier serve your traffic pattern without errors? How stable is the output for a fixed prompt? How fast is the server when it is cold? And what happens when the quota runs out? Keep the prompt identical across calls so the output variance actually means something.

# accept_free_tier.py — a template, not a benchmark
# Usage:
#   python accept_free_tier.py \
#     --endpoint https://api.example.com/v1/chat/completions \
#     --token $TOKEN --model default --calls 50

import argparse
import statistics
import time

import httpx

PROMPT = 'Repeat this sentence exactly: free tier acceptance test.'

def main() -> None:
    parser = argparse.ArgumentParser(description='Free-tier acceptance test template')
    parser.add_argument('--endpoint', required=True)
    parser.add_argument('--token', required=True)
    parser.add_argument('--model', default='default')
    parser.add_argument('--calls', type=int, default=50)
    args = parser.parse_args()

    payload = {
        'model': args.model,
        'messages': [{'role': 'user', 'content': PROMPT}],
    }
    headers = {'Authorization': f'Bearer {args.token}'}
    latencies: list[float] = []
    outputs: list[str] = []
    failures: list[tuple[int, str]] = []

    with httpx.Client() as client:
        for i in range(args.calls):
            start = time.perf_counter()
            try:
                response = client.post(args.endpoint, headers=headers, json=payload, timeout=60)
            except httpx.TimeoutException:
                failures.append((i, 'timeout'))
                continue
            elapsed_ms = (time.perf_counter() - start) * 1000
            latencies.append(elapsed_ms)
            if response.status_code == 200:
                outputs.append(response.json()['choices'][0]['message']['content'])
            else:
                failures.append((i, f'HTTP {response.status_code}'))

    if latencies:
        ordered = sorted(latencies)
        p95 = ordered[min(len(ordered) - 1, int(len(ordered) * 0.95))]
        print(f'p50 latency: {statistics.median(latencies):.0f} ms')
        print(f'p95 latency: {p95:.0f} ms')
    print(f'successful calls: {len(outputs)}/{args.calls}')
    print(f'distinct outputs: {len(set(outputs))}')
    print(f'failures: {failures}')

if __name__ == '__main__':
    main()

The response schema will differ between providers, so expect to adjust the JSON path for the message content. What matters is the shape of the output: latency, error rate, determinism, and failure behavior.

How to run the audit in five steps

Step 1: Write down the claim before you run anything

Open the project repository and record the exact quota terms — is the token grant per day, per month, or one-time, and does the free server sleep after inactivity? Those written-down assumptions are your null hypothesis, and they give you something concrete to falsify later.

Step 2: Probe the cold start

Deploy a trivial endpoint to the free server, wait ten minutes, fire a single request, and measure the time to first byte. Repeat three times, because the first call after idle is the one your users will actually experience.

Step 3: Run the script and record three numbers

Run the acceptance script with fifty calls and write down the p95 latency, the share of non-200 responses, and the count of distinct outputs for the fixed prompt. The last one is the quiet killer: if a model returns three different phrasings for the same instruction, your agent's tool-call parser will feel it long before you do.

Step 4: Exhaust the quota on purpose

Send requests until you hit the limit and then observe the failure mode, because a clean 429 with a Retry-After header is honest, while a hanging connection or a 200 with an empty body is a trap. This single test decides whether the tier is usable at all.

Step 5: Record the results and set a re-run date

Write the numbers into a small table and schedule the next run, since free tiers change faster than their documentation. Treat the results as a snapshot of one afternoon, not a certificate of permanent behavior.

Metric	Threshold I would use	What it tells you
p95 latency	under 2,000 ms for interactive use	server scheduling quality
non-200 rate	under 1% over 50 calls	quota and rate-limit behavior
distinct outputs	exactly 1 for a fixed prompt	output determinism
failure at exhaustion	clean 429, no hangs	operational honesty

What this means for MonkeyCode

MonkeyCode's offer is a reasonable starting point for this kind of experiment, mainly because the project is open source and the implementation is available for inspection instead of being hidden behind a pricing page. You can deploy the free server option and run the script above against the real endpoint, which is exactly the workflow this article argues for. If the tier fits your workload, you have a cheap place to prototype; if it does not, you have lost an afternoon, not a quarter.

Who should not use this approach

Teams with a production SLA, workloads that handle regulated data, or systems that need guaranteed throughput should not build on a free tier at all, no matter how clean the acceptance test looks. The script is also a template, not a benchmark, so treat its output as directional evidence rather than a formal measurement. And remember that token grants and server policies change, which is why the re-run date in step 5 matters more than the initial pass.

The position, stated plainly

Free AI infrastructure is worth using, but only as a measured experiment, never as an assumed fact. Limitations are useful precisely when you know their exact shape, and the only way to learn that shape is to test it yourself. If you want to try MonkeyCode's free tier, clone the repository, spend an hour running this audit, and let the numbers, not the README, tell you whether it works for your use case.

MonkeyCode provides free models that can run this workflow.

Fit FastAPI AI Apps in 256MB by Streaming Remote APIs

Alex Zhu — Fri, 04 Sep 2026 07:24:05 +0000

Free-tier AI apps die with Out of Memory because a local model plus FastAPI easily exceeds 1GB of RAM. I keep the server as a thin streaming proxy to a remote model API so baseline RSS stays around 50–100MB, and a 256MB free tier stays up.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Memory, Not CPU, Is What Kills Free-Tier AI Apps

Free server tiers typically offer 256MB or 512MB of RAM, a shared CPU, and a small disk. For a low-traffic prototype, CPU and bandwidth almost never take the process down. Memory does. When RSS walks past the limit, the OS kills Python with no stack trace that points at transformers or a buffered response.

I have watched a “simple” summarizer import torch, load a checkpoint, and sit above 1GB before the first request. That is not a hosting problem; it is a design problem. Buying a bigger box only hides it. I treat 256MB as a hard budget: the web process stays stateless, and inference happens on a remote API.

Side by side, the two shapes of an AI app are not close:

Approach	Baseline memory	ML libraries loaded	Fits a 256MB free tier?
Local model inference	1GB+	Yes (`torch`, `transformers`)	No
Remote model API + streaming	~50–100MB	No	Yes

The second row is the whole strategy: do not load the model where the request lands. Extra uvicorn workers multiply RSS, so on a 256MB box I run a single worker.

A practical contrast I use when reviewing a prototype:

Local path: from transformers import pipeline at import time — RSS jumps before app even starts.
Remote path: import httpx only — the process is a JSON-and-bytes shuttle.
Buffering path: collect every SSE chunk into a list, then return — peak RSS tracks output length.
Streaming path: yield each line — RSS stays flat on a short summary and on a long chat.

Three Principles I Use to Stay Under 256MB

I apply these in order: first remove the model from the process, then stop buffering, then cut packages until the memory probe looks boring.

1. Load nothing I do not need at startup

I never import transformers or torch on the free-tier server. Those imports dominate RSS before from_pretrained even runs. HTTP calls to a model API turn the app into a proxy: validate the payload, forward it, stream the result. That one decision cuts baseline memory by about an order of magnitude versus local inference.

In practice I keep torch, tensorflow, transformers, and onnxruntime out of the web image. The model lives behind MODEL_URL; the server image stays ignorant of checkpoints.

2. Stream every token

If I buffer a full completion, I pay for peak size. A long summary or a chatty reply then becomes a liability on a 256MB box. Streaming tokens as they arrive keeps RSS flat regardless of output length. That matters for summarization and chat, where hundreds of tokens are normal.

I keep stream: True on the upstream request and yield lines as httpx delivers them. I do not join chunks into a string “for logging.” If I need logs, I log status and latency—not the full text.

3. Audit every import

Each extra package raises the floor. I measure RSS after startup, then again after a few requests. Unused packages go; standard-library tools stay. A lean requirements.txt is the cheapest way to stay under a free-tier ceiling.

My audit loop:

Boot the app and print RSS.
Hit /summarize with short and long inputs.
Print RSS again. If it climbed, I look for caches, global lists, or a client that was never closed.
Remove one dependency, rebuild, and repeat until the number is boring.

psutil is for profiling only. It does not ship in the production image.

A Minimal FastAPI Summarizer That Never Loads a Model

This app summarizes text by calling a remote chat-completions API. It loads no ML libraries, so baseline memory stays tiny, and it streams tokens back to the client.

from fastapi import FastAPI
from fastapi.responses import StreamingResponse
import httpx
import os

app = FastAPI()
MODEL_URL = os.getenv("MODEL_URL", "https://api.example.com/v1/chat/completions")

@app.post("/summarize")
async def summarize(payload: dict):
    text = payload["text"]

    async def generate():
        async with httpx.AsyncClient(timeout=30) as client:
            try:
                async with client.stream("POST", MODEL_URL, json={
                    "model": "free-model",  # verify the model name in the docs
                    "messages": [
                        {"role": "user", "content": f"Summarize this in 3 bullets:\n{text}"}
                    ],
                    "stream": True,
                }) as response:
                    async for line in response.aiter_lines():
                        if line.startswith("data: "):
                            yield line[6:] + "\n"
            except httpx.HTTPError as exc:
                yield f"error: {exc}\n"

    return StreamingResponse(generate(), media_type="text/plain")

Notice what is missing: no transformers, no torch. Runtime dependencies are fastapi, httpx, and uvicorn. The remote model does the compute; this process only shuttles bytes. If I strip the base image far enough, I can run this shape on 128MB of RAM. On a 256MB free tier there is actual headroom.

How I wire it in practice:

Put the endpoint in MODEL_URL so the image is not tied to one vendor.
Keep stream: True upstream and yield SSE data: lines as they arrive.
Use a 30-second timeout so a hung upstream cannot pin the worker forever.
Do not accumulate the full summary in a list “just to log it”—that undoes the streaming win.
Validate that text exists and cap its length before calling the API so a huge payload cannot balloon memory in the proxy itself.

Compared with a local pipeline("summarization") service, this file has no weights, no CUDA check, and no tokenizer. The tradeoff is network latency and a dependency on an external API. For a free-tier prototype I accept that tradeoff every time.

Measure RSS, Slim the Image, Then Deploy

I cannot optimize what I do not measure. After startup—and again after a handful of requests—I print RSS:

import psutil
import os

def memory_usage_mb():
    process = psutil.Process(os.getpid())
    return process.memory_info().rss / 1024 / 1024

print(f"Baseline RSS: {memory_usage_mb():.1f} MB")

If baseline exceeds 200MB on a 256MB tier, something is wrong: a heavy import, a global cache, or a leftover debug tool. For Python-level allocations I use tracemalloc to find the exact lines.

Deploy steps I follow:

Keep requirements.txt to fastapi, httpx, and uvicorn. Add psutil only while profiling, then remove it.
Use a minimal image such as python:3.11-slim.
Build and push; confirm the image stays under ~200MB.
Set MODEL_URL to the remote chat-completions endpoint.
Start with uvicorn main:app --host 0.0.0.0 --port 8000 and a single worker.

That image plus a 50–100MB process fits a typical 256MB free tier with room for the OS.

This pattern is not for every app. I skip it when I need offline inference, single-digit millisecond latency, or a policy that forbids sending data to an external API. I also skip it when traffic is bursty or high-volume and free-tier rate limits would break the app. Prototypes, internal tools, and low-traffic MVPs are the fit—not production workloads with strict SLAs.

MonkeyCode provides free model access and a free server option, which matches this architecture. The server stays small because the model runs remotely, and the free token allowance lets me experiment without watching a bill. As with any free tier, I verify current limits in the official documentation before I depend on them.

Free infrastructure teaches me to respect constraints. Designing for memory first produces apps that are easier to deploy, cheaper to scale, and simpler to reason about. The next time an AI app dies on a 256MB box, I reach for a memory profiler—not a bigger plan.

Copy the slim FastAPI proxy above, set MODEL_URL to a remote chat-completions endpoint, keep stream: True, and print RSS on boot and after a few requests. Confirm baseline stays around 50–100MB before you add features. Then run that experiment on a 256MB free tier—MonkeyCode’s free model access and free server option are a reasonable place to start, after you check the official docs for current limits. Ship the smallest version that works, and only then grow the app.

Stop Orphaning AI Shortcuts: A Team SOP You Can Paste Into the Wiki

Alex Zhu — Thu, 03 Sep 2026 14:51:32 +0000

You merge a Friday afternoon pull request that an assistant drafted in about twenty minutes. The tests are green, the description sounds confident, and nobody wants another meeting before the weekend. On Monday a cache key collides in production, and the shortcut lives in a helper nobody remembers writing. The thread then asks a painful question: who actually owns the debt that cheap generation just created?

Cheap generation does not make maintenance cheap, and that gap is now a team operations problem. Assistants draft glue code, copy nearby patterns, and leave TODOs that never become tickets. Your wiki probably explains how to open a pull request, yet it rarely explains who files, ranks, and retires the shortcuts those pull requests leave behind. This article gives you a paste-ready SOP, a decision table, and a proposed overnight scanner you can run without inventing a new process religion.

Why this SOP is not another review checklist

Pre-merge review still matters, but it cannot see debt that only appears after traffic, retries, and a second feature land on the same file. Reviewers already drown in volume, so they approve local correctness and miss ownership. You need a post-merge queue with named humans, not another comment macro that everyone learns to ignore. Treat AI-shipped shortcuts like incoming incidents: they need a clerk, an author, a reviewer, and a service owner who can accept risk in writing.

The workflow below assumes your team already ships with assistants somewhere in the loop. It does not require you to ban those tools, and it does not pretend a linter can replace architecture judgment. It only forces every detected shortcut onto a ticket with an owner before the next merge wave buries it. If that sentence feels heavy, you are the audience this SOP is for.

Roles that keep the queue honest

Name four seats and rotate the first one weekly so the queue cannot stick to one volunteer. Write the names on the wiki page, not in a chat pin that disappears after two standups. If a seat is empty, you do not run the scanner that night; an unowned queue is how this process rots.

Debt Clerk (rotating). Opens or updates tickets from the overnight queue, and refuses to close items that lack an author.
Authoring Engineer. The person who merged the change; they confirm intent, add reproduction notes, and propose a repayment patch or an accept-risk statement.
Debt Reviewer. Someone other than the author; they challenge severity, reject fuzzy titles, and send thin tickets back to the clerk.
Service Owner. Accepts documented risk, schedules repayment on a dated backlog, or escalates when the shortcut sits on a production path.

On-call is not a fifth planner. Page on-call only when a queue item is tagged prod-risk and a customer-facing symptom already exists. Everything else waits for working hours so you do not train the team to treat TODOs like pages.

Decision table you can enforce in standup

Use this table as the only ranking language allowed on tickets. If a clerk cannot pick one row, the item goes back to needs-triage instead of getting a heroic guess. Proposed example: copy the table into your wiki and refuse screenshots of it in Slack.

Signal on the change	Default severity	Next handoff	Allowed exit
Comment or name contains TODO, HACK, FIXME, or `ai-generated`	`s3-cleanup`	Clerk → Author	Repayment PR or dated won't-fix
New `except Exception`, swallowed error, or retry without jitter	`s2-correctness`	Author → Reviewer	Test plus patch, or owner accept-risk
Cache key, authz check, money math, or PII field touched	`s1-prod-risk`	Reviewer → Service Owner	Owner-dated plan or rollback
Duplicate helper beside an existing module	`s3-cleanup`	Clerk → Author	Delete or merge the duplicate
Scanner noise, generated lockfile, or vendor folder	`s4-ignore`	Clerk closes with reason	No ticket

You should read severity as cost of delay, not as moral failure. An s3-cleanup that sits for a month is still cheaper than a vague s1 that nobody believes. The reviewer exists to stop severity inflation, which is how these queues die.

Seven numbered steps from clone to wiki

Follow the steps in order the first week, then keep only the overnight job and the standup pass. Label this a proposed workflow until your team has run it against one real repository. Do not start by scanning the entire monorepo history or you will drown the clerk on day one.

Pick a blast radius. Limit the first scan to the service that merged the most assistant-touched diffs this month, not the whole company org.
Freeze the marker list. Start with TODO, FIXME, HACK, XXX, nosec, type: ignore, and ai-generated so arguments happen in the wiki, not in the scanner.
Run the scanner once by hand. File nothing until you have spent fifteen minutes rejecting obvious noise with the clerk and the service owner together.
Turn on the overnight job. Write JSON to a known path, then let the clerk open tickets from that file during the first hour of their rotation.
Handoff in the ticket, not in chat. Author, reviewer, and owner fields are required; a missing owner blocks the next merge to that package if you already use CODEOWNERS.
Close only through the table. Every closed ticket cites a row, a commit, or a dated accept-risk note signed by the service owner.
Review the SOP monthly. Add a marker only when two incidents share it; delete a marker when it produces mostly s4-ignore for two weeks.

Those seven steps are the entire operating cadence. If your team wants a dashboard before step three, you are decorating the process instead of staffing it. Resist that urge for one month and judge the SOP by closed s1 and s2 items, not by chart polish.

Proposed artifact: an overnight debt queue scanner

The script below is a proposed example you can adapt; it is not a claim about any production deployment. It walks a repository, records matching lines, and writes a stable JSON queue the clerk can read. Optional summarization uses whatever OpenAI-compatible chat endpoint you already export in the environment, and it stays silent when those variables are absent.

#!/usr/bin/env python3
"""Proposed overnight scanner for AI-era shortcuts. Adapt before you cron it."""
from __future__ import annotations

import json
import os
import re
import sys
import urllib.request
from dataclasses import asdict, dataclass
from datetime import datetime, timezone
from pathlib import Path

MARKERS = (
    "TODO",
    "FIXME",
    "HACK",
    "XXX",
    "nosec",
    "type: ignore",
    "ai-generated",
    "generated-by-assistant",
)
SKIP_PARTS = {".git", "node_modules", "dist", "build", "vendor", ".venv"}
CODE_SUFFIXES = {".py", ".ts", ".tsx", ".js", ".go", ".rb", ".java", ".rs"}

SEVERE_HINTS = re.compile(
    r"cache|authz|authoriz|token|password|pii|gdpr|money|invoice|retry", re.I
)

@dataclass
class Finding:
    path: str
    line: int
    marker: str
    text: str
    severity: str

def iter_files(root: Path):
    for path in root.rglob("*"):
        if not path.is_file() or path.suffix.lower() not in CODE_SUFFIXES:
            continue
        if any(part in SKIP_PARTS for part in path.parts):
            continue
        yield path

def classify(text: str) -> str:
    if SEVERE_HINTS.search(text):
        return "s1-prod-risk"
    if "except Exception" in text or "rescue StandardError" in text:
        return "s2-correctness"
    return "s3-cleanup"

def scan(root: Path) -> list[Finding]:
    findings: list[Finding] = []
    for path in iter_files(root):
        try:
            lines = path.read_text(encoding="utf-8", errors="replace").splitlines()
        except OSError:
            continue
        for idx, raw in enumerate(lines, start=1):
            for marker in MARKERS:
                if marker.lower() in raw.lower():
                    findings.append(
                        Finding(
                            path=str(path.relative_to(root)),
                            line=idx,
                            marker=marker,
                            text=raw.strip()[:240],
                            severity=classify(raw),
                        )
                    )
                    break
    return findings

def maybe_summarize(findings: list[Finding]) -> str | None:
    base = os.getenv("LLM_BASE_URL")
    key = os.getenv("LLM_API_KEY")
    model = os.getenv("LLM_MODEL")
    if not base or not key or not model:
        return None
    payload = {
        "model": model,
        "messages": [
            {
                "role": "system",
                "content": "Summarize debt findings for a clerk. No extra advice.",
            },
            {
                "role": "user",
                "content": json.dumps([asdict(item) for item in findings[:40]]),
            },
        ],
        "temperature": 0,
    }
    req = urllib.request.Request(
        base.rstrip("/") + "/chat/completions",
        data=json.dumps(payload).encode("utf-8"),
        headers={
            "Authorization": f"Bearer {key}",
            "Content-Type": "application/json",
        },
        method="POST",
    )
    with urllib.request.urlopen(req, timeout=45) as resp:
        body = json.loads(resp.read().decode("utf-8"))
    return body["choices"][0]["message"]["content"]

def main() -> int:
    root = Path(os.getenv("REPO_ROOT", ".")).resolve()
    out = Path(os.getenv("QUEUE_PATH", "debt-queue.json"))
    findings = scan(root)
    report = {
        "generated_at": datetime.now(timezone.utc).isoformat(),
        "root": str(root),
        "count": len(findings),
        "findings": [asdict(item) for item in findings],
        "model_summary": maybe_summarize(findings),
    }
    out.write_text(json.dumps(report, indent=2), encoding="utf-8")
    print(f"wrote {len(findings)} findings to {out}")
    return 0

if __name__ == "__main__":
    sys.exit(main())

Run it once in the foreground so you can see the noise before any ticket exists. Keep the first command boring, local, and easy to paste into the wiki beside the SOP.

python3 debt_queue.py
REPO_ROOT=. QUEUE_PATH=/tmp/debt-queue.json python3 debt_queue.py
python3 - <<'PY'
import json
from collections import Counter
from pathlib import Path
data = json.loads(Path("/tmp/debt-queue.json").read_text())
print(Counter(item["severity"] for item in data["findings"]))
PY

If you later want a one-line overnight summary, export LLM_BASE_URL, LLM_API_KEY, and LLM_MODEL for a chat endpoint you already trust. Leave them unset on the first nights so the clerk learns the raw queue instead of a fluent paragraph that hides duplicates. The JSON file is the source of truth; the model summary is an optional cover letter.

Where a free server actually helps

You want this job off laptops because clerks forget to run scripts, and forgotten scripts become folklore. A small always-on host with a nightly timer is enough: clone or fetch the service, run the scanner, and publish debt-queue.json to the same wiki attachment or artifact bucket the clerk already opens. MonkeyCode's free model access and free server option can host that overnight pass when you already work in that workspace and need a place that is not a personal notebook. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Do not treat any free tier as a capacity plan, an SLA, or a benchmark. Keep secrets out of the scanner, keep the repository clone read-only, and keep the model call optional so the SOP still works when the endpoint is down. If the free server disappears tomorrow, the wiki roles and the decision table remain the useful part of this article.

A proposed timer looks like the following unit. Adjust paths, then have the clerk confirm the JSON timestamp before standup rather than trusting a green systemd state.

# proposed /etc/systemd/system/debt-queue.timer
[Unit]
Description=Overnight AI shortcut queue

[Timer]
OnCalendar=*-*-* 05:15:00
Persistent=true

[Install]
WantedBy=timers.target

# proposed /etc/systemd/system/debt-queue.service
[Unit]
Description=Scan repo for orphaned shortcuts

[Service]
Type=oneshot
WorkingDirectory=/srv/debt-scan/repo
ExecStart=/usr/bin/git fetch --quiet origin
ExecStart=/usr/bin/git checkout --quiet --detach origin/main
ExecStart=/usr/bin/python3 /srv/debt-scan/debt_queue.py
Environment=REPO_ROOT=/srv/debt-scan/repo
Environment=QUEUE_PATH=/srv/debt-scan/debt-queue.json

One-page wiki paste

Copy the block below into your team wiki as a single page. Replace the bracketed seats during the first rotation meeting, and stop editing prose until you have closed ten tickets through the table.

# AI shortcut debt SOP (one page)

Purpose: every assistant-touched shortcut gets an owner before it becomes folklore.

Seats this week
- Debt Clerk: [name]
- Backup clerk: [name]
- Service owner: [name]

Cadence
1. 05:15 host writes /srv/debt-scan/debt-queue.json
2. Clerk files or updates tickets before 10:00 using the decision table
3. Authors reply within one working day
4. Reviewer challenges severity the same day
5. Service owner dates repayment or signs accept-risk on Fridays

Handoffs
- Scanner -> Clerk (JSON only)
- Clerk -> Author (ticket assignee)
- Author -> Reviewer (severity + patch or accept-risk draft)
- Reviewer -> Service owner (s1 always, s2 when disputed)
- On-call only for s1 with a live customer symptom

Exit rules
- Close with commit SHA, or with owner-dated accept-risk
- No Slack-only closures
- Empty seat means the scanner stays off

Out of scope
- Full architecture redesigns
- Vendor folders and lockfiles
- Personal laptops as the nightly host

That page is deliberately dull. Dull pages get followed; clever pages get debated. If someone wants to add a flowchart, ask them to close three s2-correctness tickets first and then propose one extra sentence, not a new microsite.

Limitations you should write under the paste

Marker scanning is noisy, and noisy queues train clerks to stop reading. Generated files, vendored code, and copied error handlers will dominate unless you maintain SKIP_PARTS with the same seriousness you maintain CODEOWNERS. A free chat model can summarize the JSON, but it can also rank a harmless TODO above a silent authorization bypass if your hints are weak. This SOP does not detect missing abstractions, wrong domain boundaries, or product bets that should never have been generated in the first place.

The process also fails when tickets outrun staffing. If the clerk needs more than one hour a morning, you shrank the blast radius too late or you allowed s4-ignore items onto the board. Stop the timer, clean the board with the service owner, and only then widen the scan. A stalled board is worse than no scanner, because it creates the fiction that debt is already being managed.

Who should not use this approach

Skip this SOP if you are a solo hobbyist with no wiki and no second reviewer, because you will just file mail to yourself. Skip it if your organization already runs a formal architecture review board that must sign every production path; a marker scanner would duplicate that authority and leak unofficial severity language into audits. Skip it if you cannot keep a read-only clone and a secret-free environment for the overnight host. Skip it if leadership wants a dashboard this week more than they want named owners on ten real tickets.

Teams that benefit are small enough to name four seats, and busy enough that assistant-authored glue is already landing every day. You will know it is working when Monday incidents point at a ticket that already had an owner, not at a helper nobody remembers writing. Run the scanner on a host you already have, paste the one-page SOP, and judge the next two weeks by closed s1 items rather than by how clever the summary sounds.