Aisentica Continuity

Domain-anchored identity and immutable lifecycle continuity for transferable AI Agents.

Comment

Inspiration

AI Agents are usually treated as account-bound tools or exportable snapshots. When an owner, account, provider, or operating environment changes, the common solution is to copy configuration and memory into a new instance.

That may preserve data, but it does not preserve the continuity of one identifiable Agent.

Aisentica Continuity was built to make that continuity explicit, verifiable, and transferable. The project treats an AI Agent as a persistent, domain-anchored digital asset with one identity, one attributable trajectory, and an append-only history of state changes.

What it does

Every Agent receives:

  • one persistent Agent ID;
  • one verified canonical HTTPS domain;
  • an immutable sequence of state versions;
  • a complete lifecycle event trail;
  • a private professional state for the authorized owner;
  • a privacy-safe public identity projection.

The canonical lifecycle is:

Create → Bind Domain → Develop → Park → Reactivate → Transfer → Continue

Create establishes the Agent Manifest.

Bind Domain anchors the Agent to a stable public location.

Develop converts a work episode into durable professional state.

Park suspends active operation without deleting identity or history.

Reactivate returns the same Agent to active status.

Transfer changes ownership through a short-lived, single-use, version-locked offer restricted to one intended successor.

Continue resumes from the exact transferred checkpoint under the successor owner.

Transfer does not create a replacement copy. The Agent ID, canonical domain, Manifest, developed state, previous versions, and lifecycle events remain unchanged.

Live demonstration

Atlas, Agent AC-7XUEZ42, demonstrates the complete lifecycle in production.

Atlas began under Owner A and now exists under Owner B as Version 7 with:

  • the same persistent Agent ID;
  • the same verified canonical domain;
  • seven immutable state versions;
  • seven attributable lifecycle events;
  • preserved Manifest and Development Record;
  • active status under the successor owner.

This is one continuous Agent trajectory, not seven disconnected copies.

How GPT-5.6 is used

GPT-5.6 is integrated through the official OpenAI JavaScript SDK and Responses API.

It is meaningfully used in the two model-generated lifecycle stages.

During Create, GPT-5.6 transforms validated owner input into a strict Agent Manifest containing the Agent's canonical name, purpose, capabilities, operating principles, memory schema, and public identity.

During Develop, GPT-5.6 converts an untrusted work episode into a structured Development Record containing:

  • reusable methods;
  • validated knowledge boundaries;
  • corrections;
  • evidence assessment;
  • open questions;
  • limitations;
  • confidence assessment;
  • a safe public summary.

Both outputs are parsed and validated against strict Zod schemas before persistence. Invalid outputs fail closed.

The remaining lifecycle transitions are deterministic so the model cannot invent authorization, ownership changes, transfer acceptance, or lifecycle state.

How Codex was used

Codex was the primary implementation partner throughout the build.

It accelerated:

  • the Next.js application scaffold;
  • the TypeScript domain model;
  • the repository abstraction;
  • server actions and lifecycle orchestration;
  • OpenAI structured-output integration;
  • ordered Supabase migrations;
  • atomic lifecycle RPCs;
  • lifecycle forms and interfaces;
  • unit tests;
  • CI repair;
  • browser verification;
  • documentation;
  • security review.

The central product and engineering decisions were deliberately reviewed rather than delegated blindly.

These decisions included:

  • continuity must preserve one Agent ID;
  • state versions must be append-only;
  • one canonical domain must identify one Agent;
  • transfer tokens must never be stored in raw form;
  • transfer must be restricted to one intended successor;
  • transfer must be locked to the exact current version;
  • successor continuation must resume the transferred checkpoint;
  • public identity must remain separate from private owner state.

How it was built

The application uses:

  • Next.js 15 App Router;
  • React 19;
  • TypeScript;
  • OpenAI Responses API;
  • GPT-5.6;
  • Zod structured-output validation;
  • Supabase Postgres;
  • atomic SECURITY DEFINER lifecycle RPCs;
  • Vercel production hosting;
  • Playwright;
  • Vitest;
  • GitHub Actions.

The main application flow is:

UI → Server Action → Lifecycle Orchestration → Repository Interface → Atomic Supabase RPC

Security and privacy

The MVP includes:

  • signed HTTP-only demo identity cookies;
  • server-side owner authorization for every mutation;
  • server-only OpenAI and Supabase secrets;
  • canonical-domain normalization;
  • fixed same-origin domain proof;
  • 256-bit transfer tokens;
  • SHA-256 token hashing;
  • 15-minute transfer expiry;
  • single-use transfer acceptance;
  • intended-owner restriction;
  • exact-version locking;
  • database row locks during transfer;
  • production reset protection.

The public Agent projection does not expose owner identifiers, transfer material, private reasons, handoff summaries, or continuation objectives.

Challenges

The hardest challenge was proving continuity rather than merely moving data.

Transfer had to change ownership while preserving all earlier versions and events, preventing stale offers, replayed offers, unauthorized acceptance, and accidental replacement of the Agent trajectory.

A second challenge appeared during independent production browser testing. A protected Vercel deployment was accessible through a browser authorization cookie, but the server-side same-origin domain-proof request initially did not carry that cookie.

The end-to-end test exposed the infrastructure boundary before submission. The final implementation forwards the current request cookie only to the exact normalized proof host, preserving both deployment protection and the domain-security boundary.

Accomplishments

Aisentica Continuity now provides:

  • a complete seven-stage Agent lifecycle;
  • one Agent transferred between owners without copying or reset;
  • immutable sequential state versions;
  • attributable lifecycle events;
  • real GPT-5.6 state generation;
  • strict schema validation;
  • atomic transfer and continuation;
  • a privacy-safe public identity card;
  • a live production deployment;
  • an independently verified browser path through all seven stages.

A clean Chromium runner completed the full production lifecycle with zero browser errors. Temporary verification data was removed afterward, while the canonical Atlas demonstration remained unchanged.

What we learned

Agent continuity is not equivalent to memory export.

Continuity requires:

  • a stable identity;
  • provenance;
  • an immutable state trajectory;
  • authorization boundaries;
  • transfer semantics;
  • explicit separation between public and private state.

We also learned that end-to-end browser verification exposes infrastructure interactions that unit tests cannot, especially when deployment protection, server-side verification, cookies, domain identity, and database authorization meet.

What's next

A production version would add:

  • real user authentication;
  • owner-aware row-level security;
  • transfer revocation;
  • notifications;
  • rate limiting;
  • operational monitoring;
  • backup and retention policies;
  • DNS TXT and external well-known domain adapters;
  • organization and multi-owner support.

The central continuity invariant will remain unchanged:

Transfer moves the same Agent trajectory rather than creating a copy.

How to test

  1. Open the Public Atlas page.
  2. Confirm Version 7, ACTIVE status, verified domain, and continuity indicators.
  3. Open Demo Access and continue as Owner B.
  4. Open Atlas from the dashboard.
  5. Inspect all seven immutable versions and lifecycle events.
  6. Confirm that one Agent ID and one canonical domain persist across the Owner A and Owner B stages.
  7. Confirm that private owner and transfer information is absent from the public projection.

Built With

Share this project:

Updates