Revision: 0.1.30 · Updated: 2026-10-30
A portable method for using AI agents across software, BI, defence and research. Start small, use existing tools, and add complexity when a real task needs it.
Read the practical guide and architecture — the public Notion home explains the method, diagrams, skills and current open choices.
Factory supplies methods and portable Agent Skills. Your chosen agent tools run the work; their native configuration and service permissions enforce access. T3 Code is our reference workspace. Codex, Claude Code or another capable native setup can also be used after checking the capabilities the task needs. Choose your own context home, tracker, source hosting and infrastructure.
| Responsibility | Purpose |
|---|---|
| Foundation | Prepare the agent environment, project foundation, and operations and maintenance needed for the work |
| AgentOps | Lead one project: investigate, assign bounded work, coordinate review and deliver within the owner's mandate |
| Work modules | Supply domain methods and checks: software, scoped defence, and future dedicated BI and research methods |
| Evaluation | Compare outcomes, defects, cost, time and human effort before recommending a change |
Independent review checks the actual result against the original requirements. By default, use two fresh reviewers: one for objective/domain evidence, one for qualitative intent, usefulness and experience. Delivery waits until both reviewers’ blocking concerns are resolved. Projects and tasks can override roles, numbers and models within their mandate and stronger requirements. Model judgments do not replace meaningful domain checks.
An optional Factory entry skill helps your own Planning Agent route requests to existing project leads. Each project keeps its own AgentOps; Factory Lab develops this method rather than managing every project.
- Your Planning Agent can ask Foundation to prepare a new or existing project. Select the project's own context home and reuse its sources, useful conventions and existing checks; prepare only missing capabilities. Link the shared method rather than copying the public guide into every project. Follow setup for the selected native tools.
- Select the declaration and skills, with their revisions. Our Lab's YAML original lives in Notion; factory.yaml is a versioned export. AgentOps reads the declaration; it does not apply settings or grant access.
- Give the project's AgentOps one bounded task. Check the result, get independent review, and deliver under the agreed authority.
Already using Factory? Use the same Foundation skill and its existing-project adoption guidance. Compare the selected reviewed revision with local adaptations, update affected routes and complete bundles, and prove discovery and use. A project shown in T3 has not automatically adopted the latest method. No extra migration agent or synchronization service is needed.
Notion is our replaceable authoring home for shared methods, policies and skills. The Factory Skills library contains their instructions and supporting files. Databricks remains a future enterprise option. Project code, data, applied configuration, technical tasks and results stay in their existing native sources. Keep one editable original.
A secret store protects stored values. When an agent must use a credential without receiving its value, a native credential broker outside the execution boundary can authenticate its service calls. Native controls and upstream service grants still enforce what the agent can access. For details, see the public Context & access guide.
This repository contains reviewed portable distributions, bounded staging/check helpers, and Factory Lab's technical work. Required references travel with each skill. Use a reviewed release without live Notion access, or read the selected Notion original and identify its revision. Changes go to their owning original before a deliberate export; no process maintains two editable copies. See source ownership and contributing.
| Step | Status and next work |
|---|---|
| Method and distribution | The #98 transition is complete. Shared methods are authored in Notion and exported deliberately. Two independent reviewers are the default. Revision 0.1.29 corrects current Lab facts and adds Foundation's Notion Skills API recipe for reading and updating whole skill directories, without changing method rules. Revision 0.1.30 records the Lab-only issue-intake selection (declaration 0.5), also without changing method rules; #80 retains live account and connector acceptance. |
| Factory Lab | AgentOps is pinned in the existing operator app. Since the 29 October maintenance, the Lab AgentOps server runs official T3 Stable 0.1.5. The three older Nightly 3796 baseline environments were retired on 30 October (stopped, disks and histories retained) and are no longer fallbacks. A same-host userdata restore returned the same pinned lead and history. Earlier that day, the native controller cold-provisioned a digest-pinned image, and worker test data persisted through a parent SIGKILL. In R7, the lead created three fresh Stable 0.1.5 workers; after repair, two independent reviews accepted, the writer resumed useful model work in the same thread after restart and verified history archives preceded cleanup (#32). A whole-service stop is not yet clean (exit 125); an idle guest TERM (exit 130) returned automatically once. Shared-client/host maintenance, updates and new-VM GUI archive restore remain under #34; boot/login startup under #83 and #34. |
| Improvement | On 30 October, rc1 completed useful model, review and delivery work from the restored Stable Ops in native Auto, with fresh Stable workers (#32). Later that day, a native schedule dispatched one queued message that started a finite lead queue, and an operator canary read and wrote skill directories through the Notion Skills API (qualification). The Lab then selected one native issue-intake routine (declaration 0.5): a T3 schedule bound to the pinned lead every 180 minutes, whose reviewed mandate admits at most two new issue outcomes per window under the existing review and budget rules; its first dispatch was observed at 11:34 UTC on 30 October 2026. Next: clean stop, boot/login, maintenance and updates, and GUI/new-VM archive restore. Later: same-session comparisons #50, ZeroShot-style loops #97, and review quality #99. General automation defaults and update ownership remain open choices. The trials retain R3's history loss, model stalls, R7's failed and interrupted review attempts and its two operator approvals, rc1's model transport failure and refused link removal, and the queue's recurring model-API "No response" failures; route evidence is limited (#32) and account evidence remains under #80. They are qualification evidence, not unattended adoption. |
| Other factories | Adopt the reviewed method project by project through Foundation, after the Lab path works. |
The qualification record separates source checks, synthetic exercises and observed native operation. A published package does not install a connection, isolate workers or establish unattended operation. The technical architecture notes explain those boundaries.
The owner decides admission and delivery by default and may explicitly delegate either for a defined scope. Keep that authority through continuation and workers; raise genuinely new material scope or risk. See the operating policy.
Substantially inspired by Zach Lloyd's Factory Stack and Warp Factories examples. Warp supplies a platform and native execution engine; this independent method assembles existing capabilities. It does not claim Warp schema compatibility.
Factory's method, code and documentation are MIT licensed. Arc’ It AI branding has separate terms. Third-party products and projects retain their own terms.