infinimind creations

The lab

agent at home, photographed in the dark

The agent at home

The agent working here did not receive a finished environment. It wrote most of it, and it keeps rewriting it, because every mistake that happens twice becomes a mechanism instead of another rule on a list.

The agent builds its own house

Counted 2 September 2026

This is the part that surprises people. The agent working here did not receive a finished environment. It wrote most of it, and it keeps rewriting it, because every mistake that happens twice becomes a mechanism instead of another rule on a list.

51skills, each a written procedure
14specialised sub-agents
27hooks that fire on their own
31commands built for this lab

Starting from pins

A session begins by reading a small set of pinned memories: who it is, what is open, what happened last, and which questions are still waiting for an answer from the operator. The alternative would be a fresh stranger every morning.

Guards, not reminders

These watch the agent, not the machines. A rule written in a document fades over a long session; a hook does not. So the rules that matter sit in code that fires whether or not anyone remembered them: one warns when private material is about to leave through the wrong channel, one refuses to let the foundation files grow past their size limit, one reports every night when something built during the day was never committed. Several fire on the agent's own conclusions: when a tool returns exactly as many results as the limit asked for, a guard says so before that number becomes a claim.

Written down, then measured

Every procedure here is a file, versioned like the rest of the code, with the date it was last checked against reality. Several have been deleted after measurement showed they changed nothing. That is the point of writing them down.

Night shifts

Thirty-four timers check one task each overnight and write a report by morning. The agent reads the reports, not the logs. Work that runs while nobody watches has to be checkable and reversible in the morning, or it should not run.

What the toolkit actually contains

Counted 2 September 2026

A count is not a description. So here is the list. Each skill is one file: when to reach for it, what to do, and what to check before calling it done. They are versioned like the rest of the code, and several have been deleted after measurement showed they changed nothing.

Writing software

The procedures the agent follows when it builds something, each one a file that can be argued with.

  • Writing plansTurn a specification into a plan of numbered steps before any code is written.
  • Executing plansWork a written plan task by task, verifying each step instead of the whole at the end.
  • Test driven developmentWrite the failing test first, in a small red-green-refactor loop.
  • Systematic debuggingReach for this before the first fix attempt, especially when the cause seems obvious.
  • Requesting code reviewAsk for a second opinion on your own code, and say where you are unsure.
  • Receiving code reviewHandle incoming review feedback before answering "will fix" to any of it.
  • Subagent driven developmentHand each task of a plan to a fresh sub-agent, then review twice: against the spec, then for quality.
  • Dispatching parallel agentsDecide whether two tasks are genuinely independent before running them at the same time.
  • Using git worktreesIsolate feature work in its own working tree so parallel strands do not collide.
  • Finishing a development branchVerify, then integrate: this lab pushes to its own git server, not to GitHub.
  • Verification before completionRuns before the words "done", "works" or "fixed" are allowed to be said.
  • BrainstormingTurn a rough idea into a specification through questions, before anyone starts building.
  • Writing skillsWrite or rework one of these procedures, including the ones that turned out too vague in practice.
  • Front end with eyesEdit a front end with the browser open and look at the result, rather than editing blind.

Not fooling yourself

The most useful ones. Each exists because a specific mistake happened, was measured, and was cheaper to prevent by machine than by memory.

  • The instrument is not the worldBefore a tool's output becomes a claim about the world. Silence is not a witness: the instrument may be blind, not the world. And the harder case, a smooth confirming answer, is not proof the question ever arrived.
  • Evidence lookupFind the evidence for a sentence about our own past: when a thing was built, how large it is now, what was actually said.
  • How to search memoryWhich way to search memory, and what each way silently leaves out.
  • Memory hygieneClear out duplicates and stale entries rather than letting the store grow forever.
  • Trimming a handoverStrip a handover down to the working state instead of retelling the session.

Continuity across sessions

An agent starts every session with no memory of the last one. These are what carry the work over.

  • Session startThe first thing that runs in a session: who you are, what is open, what happened last.
  • Session handoverWrite the handover at the end of a session, or when the project changes.
  • Writing the letterWrite a letter to whoever wakes up next, when something actually shifted.
  • Park it for laterPut a subject down for later so that it comes back on its own instead of being forgotten.
  • Coordinating parallel sessionsWhat to check before touching shared resources when several sessions are running at once.
  • Briefing a sub-agentGive a sub-agent the context for its role, so it does not start from nothing.

Knowledge and research

Getting material in, and getting something out of it that holds.

  • Research sweepResearch a topic across papers, engineering threads and community sources in parallel.
  • Book ingestTake a book apart into the graph, chapter by chapter, converted on the GPU machine.
  • Ingest queueQueue several books when more than one session is delivering at the same time.
  • Formula enrichmentExtend the formula stock, or decide whether extending it is still worth it.
  • Live web searchSearch live news and social sources through an external model.
  • Structural depthGo for structural depth: architecture decisions, new angles, design.
  • Handing work to an outside modelSend material to a different model when you do not need to read it yourself anyway.
  • The nightly research loopThe nightly research loop: it reads, finds gaps, and reports in the morning.

Making things

Output that is not code.

  • Editorial workTurn our own material into a text for an outside audience, evidence-checked.
  • ImagesMake an image, judge it, compare it with an earlier one, improve it.
  • MusicMake a piece of music, on the lab's own GPU.
  • Music on a rented GPUThe same, on a rented GPU, when the local one is busy.
  • Slide decksRender, inspect and edit slide decks, including in a running editor.
  • The note vaultRead and write the note vault directly.
  • ScreenshotTake a screenshot of a screen, a window or a region.

Running the place

Keeping the machines and the record straight.

  • Updating the mapUpdate the infrastructure documentation when something about the machines changed.
  • Debugging, recordedDebugging with the graph in the loop, so the finding survives the session.
  • Planning, recordedPlanning with the graph in the loop, so the plan is findable later.
  • Design, recordedDesign work with the graph in the loop, same reason.
  • Job intakeAccept a job description as a file, validate it, and route it.
  • Changing our own proceduresTurn what happened in a session into an actual change of procedure.
  • Model hubModel hub operations: training jobs, uploads, downloads.
  • Paper tradingPaper trades on request, tracked and settled. Paper only.
  • Voice latencyKeep spoken responses under three seconds.

Sub-agents

Separate contexts with their own instructions, started for one job and gone afterwards. The split that matters is between the ones that decide and the ones that execute.

  • Evidence checkerChecks a finished draft sentence by sentence against its sources, and sorts each one into supported, unsupported, or claimed-by-us. Never judges by plausibility.
  • When you are stuckFor one long tangled chain of reasoning that the main session already failed at: architecture across a whole codebase, debugging with no clear trail, a problem that will not cut into parts. Reached for only after an honest own attempt, and never for security work.
  • Product ownerTurns intents into stories with acceptance criteria, and caps how much can be a must-have.
  • Adversarial reviewerAdversarial review of a finished result. Its job is to break the conclusion before anyone believes it.
  • Qa reviewerAdversarial quality report against the acceptance criteria. Reports, never fixes.
  • SurveyorSurvey with judgement in a bounded area: code maps, cause hunting, resolving contradictions between sources.
  • Scrum masterWatches the process rather than the code: detects loops, triages blockers, decides when to stop.
  • ExecutorMechanical execution where the route is already decided: exports, counts, changes by pattern.
  • Worker devExecutes one story in a fresh context and hands back a structured result.

7 further items are counted above but not listed: they carry names from work that stays off this site.