Autonomous

AI first task is to go through a process that gains state of all active and unfishable projects and builds which translates to down to the file operator management to prevent file corruption and more.

Comment

June of 2025 I started working with GPT and through theories about how a simple markdown file organized in certain ways with directed navigation could be more effective, easier to operate, and just as fast for modern AI's as navigating vector indexed regressions of memories. It was some deep stuff yet it was just make believe even filled with theories of memory compression. Fast forward 2 months and with the adoption of the model context protocol in August of 2025 the basics of the theories were lade out through hard coded tools that took notes when certain things triggered and retrieved those notes by relative routing back to context which i saved in a folder on my computer where I also mirrored my google drive. Just by following instructions in preferences of most AI I tried this with that had access to my google drive was able to follow along as if it was one combined brain. Later through tunneling mcp connectors almost any AI can read and write into the system. It keeps tracks of projects in what are called loafs and every operation whether part of a loaf or not is tracked with breadcrumbs to which they are tagged for ownership and state and can be identified by any AI as they are also stored on the drive. Eventually the folders in the drive grew to a group of folders I call volumes, and before skills were a thing we were already using some core volumes to be the home of operating files that provided us information on how to engage in certain actions when the router (we called lazy loading) identified an operator it turned the volume up and the information from only specific lines of the operating file get used to influence output. What ended up happening were live skills through the volumes that we operated like a library with card catalogs and table of contents that broke down every operating file and how to navigate different volumes to get to relevant information. We since have developed quite a bit further and run a local embedding service that gets checked by the highest level AI available every night. All of this is through my subscription without a GPU. We originally built a custom GPT and then later designed an MCP that we still used today called programmer where it built Autonomous and all the other things that I use including the overnight scheduled windows tasks to maintain everything. It grows automatically after completing breadcrumbs when there is something new, specific, and reusable to learn. It also will do that from other trigger words and concepts. I am also including below the system when engaged what its interpretation of what it can do (and this was from a read only GPT 5.6 pro, when the tunnel was down).

CPCCC — Autonomous Memory Edition

Inspiration

CPCCC began with a simple frustration: I was spending too much time copying context from one AI session into the next.

The models were capable, but their continuity was fragile. A decision made in one conversation could disappear in a clean session. A procedure learned after a failure might need to be explained again. An interrupted task could be resumed only if I manually reconstructed what had happened, why it happened, what had already been proven, and what still remained. Using more than one session made the problem worse because each session could have a different partial view of the same project.

The deeper problem was not only memory loss. It was work ownership. When several sessions can see the same files and projects, the system must know which session owns each active task, what files or targets it is allowed to change, when it last worked on them, and whether another session may safely continue the work. Without that, “shared memory” can become shared confusion or accidental double work.

That is where the name Copy Paste Compute Command Center came from. The original goal was to replace repeated copy-and-paste context with a durable operating layer that any authorized agent could read. Over time, that grew into CPCCC: a system for persistent memory, active-work state, ownership, learning, verification, and coordination across AI sessions.

The core design decision was that the user—not a model vendor and not a hidden database—should own the memory. Important knowledge should remain readable as ordinary files, inspectable by a human, versionable with standard tools, and available even if an index or AI service is unavailable.

For OpenAI Build Week, we focused that larger system into CPCCC Autonomous — Memory Edition: one self-contained MCP runtime that gives GPT-5.6 and Codex shared, human-owned memory, durable project continuity, explicit session ownership, and a verified learning lifecycle.

What it does

CPCCC Autonomous — Memory Edition gives GPT-5.6 and Codex one shared memory, work-state, and continuity layer through a single MCP server.

Its source of truth is a user-owned Volume of human-readable Markdown files. Those files store durable decisions, procedures, corrections, preferences, discoveries, failures, project state, active work, and ownership records. Search indexes and relation graphs improve speed, but they are rebuildable projections rather than the final authority. The files remain canonical.

Autonomous operates that Volume end to end. It can:

  • boot a clean agent into the current project, memory, and active-work state;
  • show which projects, tasks, and mutable targets are assigned to which session;
  • record the owner, session identity, target files, and last activity for each in-flight operation;
  • prevent a second session from silently writing over work that is actively owned elsewhere;
  • support explicit, logged project or task takeover when ownership must move between sessions;
  • route questions to the correct topic and exact source section;
  • combine deterministic navigation, keyword search, semantic retrieval, and typed relations;
  • create and update canonical memory with versioning and propagation checks;
  • classify durable learnings as decisions, procedures, corrections, discoveries, preferences, patterns, or anti-patterns;
  • attach provenance and relationships such as caused_by, enables, contradicts, and supersedes;
  • detect duplicates, stale knowledge, broken references, and conflicting records;
  • track active operations, plans, steps, checkpoints, interruptions, approvals, and handoffs;
  • restore unfinished work in a completely new Codex session;
  • test whether a newly written memory can be recalled from likely future questions;
  • record when a memory was used and whether following it produced a successful outcome;
  • maintain the knowledge base through evaluation, consolidation, lifecycle review, and health checks.

Session ownership and controlled takeover

Every active project or task is associated with a durable work record. That record identifies the owning agent and session, the targets it may change, its last activity, completed evidence, remaining work, and next action.

A new session can therefore ask:

  • What projects are active?
  • Which session owns this task?
  • When did that session last work on it?
  • What has already been completed and verified?
  • Which files are currently checked out for change?
  • Is the prior owner active, idle, finished, or waiting for a decision?
  • Is takeover allowed, and on what basis?

Ownership transfer is deliberately more controlled than ordinary recall. By default, taking over work from another live session is one of the few approval-gated actions. Owner policy may permit a logged takeover after a defined idle threshold, but a transfer is never silent: it changes the durable owner, preserves the prior session’s history, and records why the transfer occurred. Idle detection transfers responsibility; it does not terminate or erase the earlier session.

Compaction-safe continuation

Long conversations eventually require context compaction. CPCCC treats that boundary as an operating event rather than an amnesia event.

Before compaction, a memory-system hook writes a continuation checkpoint containing the current goal, session owner, original plan, completed proof, changed targets, pending work, unresolved decisions, risks, exact source pointers, and next action. It also reviews the conversation for durable corrections, decisions, discoveries, patterns, and anti-patterns that should enter long-term memory.

After compaction, the session reloads that checkpoint and continues from the same verified state. Because the checkpoint is compiled from the durable operation record—not merely from the final few messages—the continuation still knows what was planned earlier in the conversation, what was actually done, and what remains unfinished.

GPT-5.6 acts as the memory curator. When a conversation or completed task contains a possible durable learning, GPT-5.6 converts it into a structured candidate: what was learned, what type of memory it is, where it belongs, what caused it, what it supersedes, and what future questions should retrieve it.

Autonomous then performs the durable work. It checks for duplicates, writes the canonical record, updates the navigation and index projections, verifies the landed content, and runs the future recall probes.

Codex acts as both a working agent and the continuity proof. A fresh Codex session can read the same Volume, identify the correct active project and owner, retrieve the exact source, recover the operation, and continue from the last verified checkpoint without receiving a copied transcript.

How we built it

CPCCC and the Autonomous engine existed before Build Week as parts of a larger personal multi-agent system. We are not claiming that the entire CPCCC platform was created during the hackathon. The Build Week work is the focused, OpenAI-facing Memory Edition and the standalone product boundary around it.

We built the project in five layers.

1. Human-owned Volumes

We kept Markdown as the canonical memory substrate. A root index routes agents into the knowledge base, a catalog maps natural-language triggers to topics, each Operating file contains an exact section map, and sidecars carry relationships to other topics. This means retrieval can still terminate correctly through file-native navigation when semantic search is unavailable.

For the public project, we use a synthetic Starter Volume rather than any private CPCCC content. It contains example projects, decisions, procedures, preferences, errors, state, work ownership, and handoffs so judges can test the full workflow without receiving personal or production data.

2. A self-contained Autonomous runtime

We isolated the memory-domain capabilities that Autonomous owns: boot, routing, retrieval, exact reads, writes, extraction, relations, project state, operation tracking, ownership, sessions, checkpoints, handoffs, evaluation, analytics, and maintenance.

We organized the same server into capability profiles so the model sees only the tools appropriate to the current job:

  • Core: boot, recall, reading, writing, project state, operations, ownership, checkpoints, handoffs, and health;
  • Learning: extraction, deduplication, patterns, anti-patterns, relations, usage, outcomes, lifecycle, and evaluation;
  • Administration: indexing, propagation, backups, consolidation, stale detection, and maintenance.

High-level memory workflows provide a simple front door, while the deeper native tools remain available when the task requires them.

3. Durable ownership and session coordination

We made work state addressable, not implied. Each active operation carries its owner, session or thread identity, target files, last activity, plan, progress, and transfer history.

Before a session mutates shared work, it can verify whether the target is unowned, held by the current session, actively held elsewhere, or eligible for takeover. An ownership transfer updates the durable work record and append-only transfer history so future sessions can explain who changed responsibility, when, and why.

This gives CPCCC two kinds of continuity at the same time:

  1. knowledge continuity — what the system has learned;
  2. operational continuity — who is doing what, what has changed, and who may safely continue.

4. Pre-compaction checkpoints and post-compaction reload

We integrated continuity with the model lifecycle. Before a context window is compacted, the hook generates a concise continuation packet from the full active operation: goal, owner, plan, completed proof, pending work, risks, pointers, and next action. It also runs the learning gate while the pre-compaction context is still available.

After compaction, the adapter reloads the operation state and canonical memory before work resumes. The model does not need to infer the project from a compressed chat summary or hope that the most important plan appeared near the end of the conversation.

5. GPT-5.6 as memory curator and Codex as build partner

We use GPT-5.6 at runtime to turn unstructured experience into structured durable-memory candidates. Structured outputs describe the memory type, canonical topic, provenance, relations, confidence, supersession state, and future recall queries.

This keeps the model responsible for interpretation and judgment while Autonomous remains responsible for persistence, verification, ownership, and lifecycle management.

Codex was used to audit dependencies, define the standalone boundary, implement and test the OpenAI-facing workflow, create the synthetic Volume, package the runtime, and exercise the end-to-end demo.

Codex also proves the product after the build. In the demonstration, a clean Codex session retrieves knowledge created in a GPT-5.6 session, identifies the active work owner, restores an interrupted operation, cites the canonical source, and continues the work after an explicit transfer or approved takeover.

Challenges we ran into

The first challenge was drawing an honest boundary around a mature system. Autonomous had grown inside a larger CPCCC environment, so simply copying the binary would not make it a coherent product. We had to generalize user-specific paths and assumptions and prove that the public workflow could run from one Autonomous runtime and one synthetic Volume.

The second challenge was balancing power with usability. Autonomous has a deep tool surface because memory is not one operation. It includes retrieval, writing, extraction, relations, sessions, operations, ownership, analytics, evaluation, and maintenance. Exposing every schema on every turn would waste context and make tool selection harder. Reducing the system to a handful of shallow tools would hide the capabilities that make it valuable. Capability profiles and high-level workflows let us keep one complete runtime without overwhelming the agent.

The third challenge was preventing cross-session collisions. Shared memory is useful only when two sessions do not unknowingly edit the same active project. We had to make ownership explicit, attach it to concrete mutable targets, track last activity, distinguish active work from idle work, and make takeover visible and auditable. The system needed to support continuity without treating silence as permission.

The fourth challenge was making compaction truly seamless. A generic chat summary is not enough to continue technical work. The system must preserve the original goal and plan, the owner, exact files, completed proof, open questions, risks, and next action—even when those plans were made long before the compaction boundary. That required joining the pre-compaction hook to durable operation state rather than relying on recency alone.

The fifth challenge was preserving one source of truth. Semantic search, full-text search, and graph retrieval are useful, but they can become a second memory that drifts away from the files. We designed the indexes to return addresses into canonical Markdown rather than detached copies of the knowledge. The system verifies the landed file content, not merely a database write.

The sixth challenge was defining what should become memory. Saving everything creates noise and makes future recall worse. GPT-5.6 therefore applies a qualification step before Autonomous writes: the learning should be reusable, specific, and new. Autonomous then adds deduplication, provenance, relations, recall probes, usage tracking, and eventual consolidation, supersession, or removal.

The seventh challenge was privacy. The system was created from real long-running work, but the submission cannot expose private Volumes, client information, credentials, internal ledgers, or production paths. We separated engine from content and built the public demo around a synthetic Starter Volume.

Accomplishments that we're proud of

We are proud that the project demonstrates a complete lifecycle rather than a single retrieval trick.

A user can teach GPT-5.6 a decision and the reason behind it. GPT-5.6 turns that experience into a structured candidate. Autonomous checks whether it is new, writes it into human-readable canonical memory, relates it to prior knowledge, updates its projections, and verifies future recall. A clean Codex session can then retrieve the exact source and use it without a copied transcript.

We are especially proud of the cross-session ownership model. CPCCC can identify every active project or task, the session that owns it, the targets it may change, when that owner last worked, and whether the work is active, idle, completed, or awaiting a decision. A new session does not simply “continue”; it first determines whether it owns the work or needs an explicit transfer. Approved takeovers are recorded rather than inferred.

We are also proud of compaction-safe continuation. The pre-compaction hook preserves the operation’s plan, owner, completed proof, unfinished work, risks, and next action. After compaction, the same session resumes from that durable packet instead of reconstructing the project from a lossy summary. This works even when the decisive plan was created much earlier in the chat.

Another accomplishment is that the memory remains useful when the fast path is unavailable. The semantic index is an accelerator, not the owner of the knowledge. File-native navigation can still resolve the same answer from the user-owned Volume.

Finally, CPCCC remembers more than facts. It can preserve operating procedures, corrections, patterns, anti-patterns, failure history, project decisions, ownership, approvals, and active task state. It remembers what the agent knows, what it was doing, who owns the work, and what must happen next.

What we learned

The biggest lesson was that persistent memory is not primarily a storage problem. It is a lifecycle problem.

A useful memory system must decide what deserves to persist, prove that it landed in the canonical source, retrieve it from likely future wording, record whether it was used, observe whether following it helped, and eventually consolidate, repair, supersede, or remove it when it becomes stale or wrong.

We also learned that task continuity and knowledge continuity belong together. A new agent session needs the project decision, but it also needs the active operation, completed steps, changed files, unresolved questions, next action, and current owner. Remembering only facts still forces the user to reconstruct the work.

A related lesson was that cross-session awareness without ownership is dangerous. Knowing that a task exists is not the same as having authority to change it. Reliable multi-session work needs an explicit owner, concrete targets, last-activity evidence, a controlled transfer process, and a durable audit trail.

Compaction taught us that continuity must be event-aware. The right moment to preserve state is before context is compressed, while the current plan and evidence are still available. But the checkpoint must be built from durable operation state, not just from the newest tokens, or early decisions will still disappear.

Another lesson was that human readability is an operational feature, not just a preference. When the canonical memory is stored as ordinary files, the user can inspect it, correct it, diff it, back it up, move it, and read it without the original model or database.

We learned to separate guidance from enforcement. Instructions and skills can teach an agent what procedure to follow, but only the runtime and host can provide the available tools, lifecycle events, permissions, and hard technical boundaries. Memory Edition reports those distinctions instead of pretending every surface provides identical guarantees.

Most importantly, we learned that confidence is not proof. A successful tool call does not mean a memory is durable, a task is complete, or a transfer is legitimate. Durability means the record exists in the canonical file, is reachable from future phrasing, survives maintenance, and remains useful in a later task. Completion means the proof and pending work were recorded. Ownership means the current session can show why it has the right to proceed.

What's next for CPCCC Copy Paste Compute Command Center

The next step is to turn Memory Edition from a hackathon package into a broadly installable personal memory runtime.

We plan to add:

  • cross-platform packaging for Windows, macOS, and Linux;
  • an encrypted and authenticated remote connector for authorized web and mobile agents—for example, a Cloudflare Tunnel transport protected by Cloudflare Access and OAuth, so the local Autonomous runtime can be reached without exposing it as a public unauthenticated service;
  • domain-specific memory lifecycle policies: active forgetting and decay for short-lived or low-value observations, active consolidation for cumulative domains such as project history and learned procedures, and owner-defined retention for domains that must preserve a complete record;
  • local-first ingestion for both internal and approved external memory sources, so personal notes, project files, imported references, and authorized external material can enter one provenance-aware Volume while the canonical memory remains under the owner’s control;
  • external long-memory benchmarks and reproducible evaluation suites;
  • a small visual review surface for new learnings, active owners, takeover requests, pending decisions, superseded records, low-value memories, and system health;
  • a guided onboarding interview that builds a new user's Volume through the same verified learning pipeline used during normal operation;
  • earned-autonomy controls that begin conservatively and expand only after the system demonstrates reliable predictions about the owner's preferences;
  • optional capability packs for coding execution, local automation, browser work, and multi-agent orchestration, each carrying domain-specific patterns, anti-patterns, permissions, ownership rules, and evaluation tests while leaving Autonomous Memory Edition complete and useful by itself;
  • stronger lifecycle analytics that connect retrieved knowledge to real task outcomes;
  • portable adapters so additional authorized AI clients can use the same user-owned memory without changing the canonical substrate.

The longer-term goal of CPCCC is not to create another AI that owns a user's history. It is to create a durable command center where authorized agents can share knowledge and active-work state while the user continues to own, inspect, and control the memory.

GPT-5.6 learns it. Autonomous verifies it. Volumes owns it. Codex remembers it. or in reverse starting with Codex and remembering it in GPT chat or work.

Built With

Share this project:

Updates