ai-career

Keeps AI agents aligned across sessions by loading governance, tracking task frames, and requiring evidence before results are adopted.

Comment

Inspiration

Long-running AI development sessions gradually lose track of what is currently being built, which decisions still apply, and what an agent is actually authorized to do.

When a session restarts or work is delegated to another agent, recent conversation can easily be mistaken for verified project state. Important task boundaries, approvals, evidence, and the current point of work become difficult to recover.

ai-career is a repository-backed collaboration runtime that keeps an AI session's active role, task, authority, evidence, and current working state explicit and recoverable.

We wanted AI collaboration to depend less on perfect conversation memory and more on state that can be inspected, validated, and resumed.

What it does

Before applying a role or mode, ai-career loads its operating rules and current project state from repository-backed sources instead of relying only on conversation context.

It establishes a Currentness Anchor for each AI session. The anchor records the active session, mode, role, task assignment, authority, supporting evidence, and observation time.

Work can be delegated through bounded Task Frames. Worker outputs return as evidence-backed candidate results rather than automatically becoming accepted project truth. The parent session must revalidate the current anchor and explicitly decide whether to adopt the result.

File mutations and other executable actions can be placed behind explicit approval, execution binding, guarded execution, and one-time receipts. This prevents an AI from treating a conversational suggestion or general approval as permission to perform an unrelated action.

Checkpoints and resume records allow a later session to recover the project's operating state without pretending that an earlier conversation is still current.

ai-career also includes a read-only Tutorial Mode. It explains the runtime structure, governance boot, Currentness Anchors, Task Frames, evidence-backed results, and guarded adoption without installing the executable runtime or modifying a project.

Because the tutorial follows instructions from the connected repository, it can also be used from a GitHub-connected mobile ChatGPT session as a lightweight explanation and orientation path.

How we built it

We built ai-career as a source-backed runtime layer around ordinary AI tools.

The core Markdown contracts define authority, currentness, task boundaries, evidence requirements, and execution permissions. An optional local Python reference runtime turns those contracts into deterministic execution state and evidence.

SQLite, Git-backed source control, local session processes, skills, host adapters, fixtures, and bounded execution guards provide persistence, integration, and validation across supported environments.

Codex with GPT-5.6 was used throughout the build rather than only for initial scaffolding. We used it to:

  • design and refine the Currentness Anchor and Task Frame contracts;
  • implement the deterministic reference runtime and derived runtime-state views;
  • separate governance boot from executable local runtime startup after discovering that the two had gradually become coupled;
  • implement task assignment, execution binding, guarded mutation, and one-time receipt validation;
  • build golden fixtures, replay-rejection tests, evaluators, and cross-host comparison evidence;
  • review documentation and runtime behavior for mismatches;
  • prepare and validate the demo and judge-facing evaluation path.

The human role remained responsible for project direction, architecture, constraints, acceptance decisions, and deciding which AI-generated results became part of the project.

Codex proposed, implemented, tested, reviewed, and revised bounded parts of the system against repository-backed requirements and validation evidence.

Challenges we ran into

The biggest challenge was separating what an AI model says from what the runtime can actually prove.

We had to distinguish:

  • conversation context from verified runtime state;
  • governance readiness from execution authority;
  • general approval from an executable task assignment;
  • a worker result from a result adopted by the parent session;
  • repository verification from an active executable session runtime.

During development, governance boot and local runtime startup gradually became coupled. This made it possible to confuse loading the operating contract with proving that a local executable runtime was active.

Restoring the separation between governance alignment and executable runtime startup became one of the largest architectural changes in the project.

We also had to handle disposable sandboxes, stale anchors, cross-session recovery, connector limitations, and different capabilities across AI hosts without reporting unsupported behavior as successful execution.

Accomplishments that we're proud of

We built and tested a complete Currentness Anchor workflow.

The runtime can:

  • load source-backed governance;
  • boot a governed session;
  • establish and advance a current anchor;
  • execute bounded tasks;
  • produce evidence-backed result packets;
  • preserve the parent session while delegated work is performed;
  • require approval before mutation;
  • issue one-time execution receipts;
  • reject receipt replay;
  • recover operating state through checkpoints and resume records.

We created a deterministic reference runtime, golden fixtures, evaluators, transparent adapters, and cross-host comparison contracts.

We also verified that source-backed governance can operate independently from the optional executable runtime.

During validation from a mobile ChatGPT session connected to an unmerged GitHub branch, ai-career successfully loaded the source-backed governance and activated the requested Mode Context without claiming that a local executable runtime was available.

This confirmed an important architectural boundary: governance alignment and executable runtime proof are related, but they are not the same thing.

We also created a read-only Tutorial Mode so users and reviewers can ask a connected AI host to explain the architecture and workflow without installing the runtime or granting modification authority.

What we learned

Reliable AI collaboration is not only a prompt-engineering problem. It requires explicit state, authority, task, evidence, and adoption boundaries.

The model should reason, while the runtime records evidence and enforces state transitions.

Currentness is not the same as the most recent conversation.

A successful command does not automatically create authority. General approval does not automatically become an executable assignment. A worker result does not automatically become project truth. Repository verification does not automatically prove that an executable session runtime is active.

We also learned that unavailable or unsupported capabilities should remain UNKNOWN rather than being simulated or inferred into success.

How to understand and test it

The simplest way to understand ai-career is through its read-only Tutorial Mode.

From a ChatGPT session with the GitHub connector available, including mobile ChatGPT, users can request:

@GitHub konezero/ai-career Read the README and run the tutorial.

The AI first reads the repository README and follows the repository-defined Tutorial Mode entry path.

Tutorial Mode provides a read-only guided explanation of the runtime architecture, governance loading, Currentness Anchors, Task Frames, evidence-backed results, and guarded adoption.

It is an explanation and orientation path. It does not install the executable runtime, modify a user project, or claim unsupported execution capabilities.

For full technical evaluation, judges can follow docs/OPENAI_BUILD_WEEK_EVALUATION.md in the repository.

The evaluation guide covers:

  1. project-local installation;
  2. Session Boot;
  3. Currentness Anchor verification;
  4. guarded file mutation;
  5. one-time execution receipts;
  6. receipt replay rejection;
  7. optional Task Frame testing.

What's next for ai-career

Our next step is to package the runtime contracts, session state, checkpoints, and evidence surfaces into a versioned release database.

This will make the runtime easier to distribute and restore across local projects and AI hosts.

A new session will be able to retrieve a release, validate its source version, boot the runtime, and continue from an evidence-backed state without rebuilding the entire environment manually.

We also plan to improve cross-model benchmarking, add more host adapters, simplify Task Frame worker invocation, and make the explanation and evaluation paths easier for new users.

Share this project:

Updates