How one person builds and operates NT² Vault with AI agents

NT² Vault is maintained by one person with AI assistance. Agents help research ideas, turn decisions into specifications, write code and tests, review changes, prepare translations, and investigate operational signals.

That does not mean an agent independently ships the product.

The real leverage comes from converting good engineering habits into a system that both humans and agents can follow:

• durable context instead of chat memory;
• one bounded work package instead of a vague feature request;
• observable acceptance criteria instead of adjectives;
• explicit approval instead of inferred consent;
• tests and review evidence instead of agent confidence;
• read-only reviewers instead of self-approval;
• limited operational capabilities instead of unrestricted production access.

This article presents that system as a reusable playbook. It does not depend on NT²’s repository layout, cloud provider, framework, package manager, or command names.

Start with the authority model

Before choosing tools, decide who is allowed to decide and who is allowed to act.

In our model:

The rule is simple:

Agents may produce decisions for review. They do not silently convert recommendations into authority.

This distinction should be encoded in the workflow, not left as an expectation in someone’s head.

1. Build a four-layer project memory

Agent performance depends less on prompt cleverness than on the quality of the project memory it receives.

A portable setup needs four layers.

Layer A — project constitution

This is a short, always-loaded document containing:

• technology and architecture boundaries;
• coding and testing rules;
• security invariants;
• prohibited shortcuts;
• rules for commits, external writes, destructive actions, and deployments.

Keep it short enough that every session can read it. Put detailed explanations elsewhere and link to them.

Example:

## Non-negotiable rules

- UI code does not write directly to persistence.
- Secrets never appear in logs, fixtures, or model prompts.
- New dependencies require justification.
- Security-sensitive code needs a separate review.
- Never commit, deploy, or send a customer message without explicit approval.

Layer B — current queue

Maintain a small, human-owned list of ready and blocked work.

Each row needs:

id: short-stable-id
title: concise outcome
why_now: one sentence
depends_on: []
status: ready

Cap the active queue. Ten items is already plenty for a small team. External trackers may mirror it, but the agent should have one canonical source.

The queue answers what next. It must not replace the feature contract that answers what exactly.

Layer C — one work package

Every shippable slice gets a versioned work package:

## Goal

What user or operational outcome should exist?

## Scope

- What will be implemented
- What will be changed

## Non-Goals

- What must not be added while doing this work

## Acceptance Criteria

- [ ] Observable success behavior
- [ ] Observable failure behavior
- [ ] Security, privacy, offline, or performance constraint
- [ ] Required automated or manual evidence

This is the agent’s execution contract.

Layer D — decision log

Record decisions that should survive the current task:

• why one storage strategy was chosen over another;
• why a capability is deliberately absent;
• what threat model changed;
• which system owns a contract;
• when a temporary constraint should be revisited.

Chat is useful for reaching a decision. It is a poor place to preserve one.

2. Give every session a narrow cold start

A new session should not begin with “read the entire codebase.”

Use this sequence:

1. Read the project constitution
2. Read the short priority queue
3. Select one work package
4. Read only the architecture and source entry points cited by that package
5. Summarize assumptions before proposing changes

This prevents three common failures:

1. Context dilution — important constraints disappear inside thousands of irrelevant lines.
2. Roadmap blending — the agent combines several partially planned initiatives.
3. stale-memory confidence — a previous chat is treated as more authoritative than current files.

Use one implementation owner per work package. Parallel agents can research independent areas, but several agents should not edit the same slice in the same working tree.

3. Write acceptance criteria that can defeat a confident agent

An acceptance criterion should let a skeptical reviewer determine whether the work is complete.

Weak:

- The screen feels polished.
- Sync is reliable.
- Error handling is good.

Strong:

- When the network is unavailable, saving still commits locally and displays
  an explicit pending-sync state.
- When the same mutation is received twice, the second application is a no-op.
- When authorization fails, no partial record is written.
- Logs contain the operation class and result, but no account identifier,
  request body, credential, or content payload.

Strong criteria describe:

• the trigger;
• the observable result;
• the failure result;
• the important invariant;
• the evidence required.

Make Non-Goals concrete

“Do not over-engineer” is not enforceable.

Use:

- No new framework.
- No schema migration in this slice.
- No redesign of adjacent screens.
- No second persistence path.
- No production rollout before staging evidence exists.

Non-Goals are especially valuable with agents because they block plausible but unrequested “improvements.”

4. Use hard human checkpoints

Our workflow has six meaningful gates:

Specify -> Plan -> Implement -> Verify -> Review -> Close

Commit and release are separate, explicitly authorized actions after Close.

At the end of Specify, the agent must ask the human to choose:

- Approve this scope
- Revise it
- Treat it as a disposable prototype

At the end of Plan:

- Approve implementation
- Re-plan
- Return to scope

At Close:

- Accept the evidence and close
- Reopen implementation
- Hold without changing status

Silence is not approval. An earlier “looks good” does not approve a later revision. A task marked “in progress” is not permission to cross the next gate.

What a plan must contain

A useful implementation plan maps every acceptance criterion to:

criterion
  -> component or boundary
  -> first failing test
  -> minimum implementation
  -> verification evidence
  -> risk and rollback consideration

Prompt template:

Plan this work package without editing files.

For every acceptance criterion, identify:
- the smallest code boundary that should change;
- the test that should fail before implementation;
- the evidence required to call it complete;
- security, migration, compatibility, and rollback risks.

Respect every Non-Goal. Flag product decisions instead of making them.

5. Implement one criterion at a time

For each code-bearing criterion, use Red → Green → Refactor.

flowchart LR
  AC[One acceptance criterion]
  RED[Write test and confirm failure]
  GREEN[Minimum implementation]
  REFACTOR[Improve structure while green]
  EVIDENCE[Record evidence]
  NEXT[Next criterion]

  AC --> RED --> GREEN --> REFACTOR --> EVIDENCE --> NEXT

Red

Write the cheapest effective test:

Run it and confirm it fails because the behavior is missing—not because the test setup is broken.

Green

Implement only enough to satisfy the current criterion. Reuse existing boundaries rather than creating a parallel architecture.

Refactor

Improve names and structure while the test stays green. Do not use refactoring as permission to expand Scope.

Evidence

For each criterion, retain:

criterion: save remains local while offline
evidence:
  automated: integration test "queues local mutation when transport is down"
  manual: offline browser walkthrough on release candidate
result: pass

The evidence ledger is more useful than “all tests passed” because it preserves the connection between product intent and verification.

6. Separate implementation from review

One all-powerful agent is fast until it confidently approves its own mistake.

Use distinct roles:

Read-only reviewers are important. A reviewer that immediately edits the code can change the design and then approve its own version.

When to parallelize

Parallelize:

• frontend and backend impact research;
• threat modeling and test design;
• documentation review and build verification;
• alternative approaches in isolated environments.

Serialize:

• final scope;
• ownership of implementation;
• schema migrations;
• release actions;
• production mutations.

7. Treat security rules as executable invariants

Security guidance should not read like “be careful.”

Write invariants such as:

- User secrets never leave the trusted client boundary.
- Encryption keys cannot be exported.
- Sensitive session material is cleared on lock.
- Every encryption operation uses a unique nonce.
- Logs and operational tools never expose plaintext content.
- Recovery behavior does not create a server-side password oracle.

Then map each invariant to:

• code review checks;
• static analysis where possible;
• unit or integration tests;
• manual security walkthroughs;
• an owner who may block release.

Define the AI data planes

Do not say merely “we use AI.”

Document each plane:

For NT², vault plaintext never goes to an AI service. Operational assistance cannot decrypt it, and customer replies are human-reviewed before send.

8. Design CI around evidence, not one giant command

A portable pipeline can be expressed as outcomes:

Gate 1: work-package structure and status are valid
Gate 2: formatting and static analysis pass
Gate 3: type and build contracts pass
Gate 4: unit tests and critical coverage pass
Gate 5: integration contracts pass
Gate 6: affected system tests pass
Gate 7: dependency and security scans pass
Gate 8: required manual evidence is attached

How these gates are invoked is project-specific. The model is not.

Run affected checks, escalate by risk

Map changed areas to the smallest trustworthy gate:

• documentation change → content, references, formatting;
• shared library → library tests plus affected dependents;
• API contract → integration tests plus affected clients;
• authentication or encryption → full security gate and manual walkthrough;
• dependency graph or build tooling → full pipeline.

This keeps feedback fast without teaching agents that checks are optional.

Make critical coverage explicit

Global percentage targets are often noisy. Identify critical modules—crypto, authorization, parsers, migrations, sync merge logic—and require stronger coverage there.

9. Separate deploy capability from deploy authority

The agent may know how to deploy. That does not mean it is authorized to deploy.

Use a release state machine:

flowchart LR
  C[Candidate]
  CI[Automated gates]
  S[Staging]
  M[Manual and operational checks]
  A[Human approval]
  P[Production]
  O[Post-deploy observation]

  C --> CI --> S --> M --> A --> P --> O
  M -->|fail| C
  O -->|regression| C

Each transition should have:

• an owner;
• required evidence;
• rollback instructions;
• environment isolation;
• an audit record.

Release checklist

## Code
- [ ] Approved work packages are closed
- [ ] Automated gates are green
- [ ] Security review is complete where required

## Staging
- [ ] Changed user journeys were exercised
- [ ] Migrations were applied and verified
- [ ] Environment points only to staging dependencies

## Production
- [ ] Human approved release
- [ ] Rollback path is ready
- [ ] Changed services are identified
- [ ] Post-deploy checks are assigned

A hotfix follows the same principles with a smaller scope and shorter timeline: branch from production state, make the minimum fix, verify the affected path, release, then reconcile the integration branch.

10. Give operations agents capabilities, not ambient access

An operations agent should not receive a shell with every credential available.

Expose narrow capabilities:

read_health_summary()
read_recent_error_buckets()
read_public_incident_status()
list_open_support_threads()
propose_incident_message()
propose_support_reply()

Separate reads from mutations:

set_maintenance_mode(value, reason, confirmation)
send_support_reply(thread, approved_body, confirmation)
apply_migration(environment, migration_id, confirmation)

Mutation contracts should require:

• explicit environment;
• human confirmation;
• reason;
• idempotency key where relevant;
• authorization check;
• audit event;
• redacted output.

The safe hierarchy is:

agent tool ⊆ operator interface ⊆ authorized service API

An agent tool must not create a privileged path that the normal operator interface does not have.

11. Use an incident loop that turns evidence into product work

When a signal changes after release:

1. Detect — identify the affected outcome, not just a noisy log line.
2. Correlate — compare the time window with releases and configuration changes.
3. Contain — disable or isolate the smallest affected capability.
4. Reproduce — use staging or a safe fixture; never experiment on user data.
5. Fix — create a bounded hotfix package with a regression test.
6. Verify — confirm the user path and the operational signal recover.
7. Learn — update an invariant, test, runbook, or acceptance criterion.

The last step is where AI assistance compounds. The incident is converted into durable context that improves every future session.

Human-in-the-loop support

AI can:

• assemble authorized account and thread context;
• find relevant public help material;
• draft a reply;
• suggest labels or routing.

AI cannot:

• request a master password or recovery secret;
• inspect private vault content;
• silently change account state;
• send a reply without human review.

The model reduces context switching. It does not become the accountable operator.

12. Apply the model to localization and content

The same pattern works outside code:

canonical source
  -> structural propagation
  -> contextual agent or human draft
  -> glossary and placeholder validation
  -> human review
  -> publish gate

Do not let an automatic translation service become an unreviewed write path for security or product terminology. Preserve placeholders, links, code, and brand terms deterministically.

13. A worked example: adding an inactivity warning

Assume another product wants to warn users one minute before an automatic session lock.

Work package

## Goal
Give an active user a chance to remain signed in before the existing idle lock.

## Scope
- Show a warning at T-60 seconds.
- “Continue session” resets the existing idle timer.
- If no action occurs, the existing lock path runs unchanged.

## Non-Goals
- No configurable timeout.
- No cross-device session extension.
- No new notification service.

## Acceptance Criteria
- [ ] Warning appears once at T-60 seconds.
- [ ] Continue dismisses warning and resets idle tracking.
- [ ] No action invokes the existing lock and clears sensitive memory.
- [ ] Background-tab behavior is documented and tested.
- [ ] No secret or activity content is logged.

Plan

AC 1 -> timer state -> unit test with fake clock
AC 2 -> existing activity reset boundary -> unit + component test
AC 3 -> existing lock coordinator -> integration test
AC 4 -> browser visibility behavior -> system test
AC 5 -> logging boundary -> review + log assertion

Human checkpoint

The human decides whether “Continue session” requires fresh authentication. That is a product/security choice, not an implementation detail for the agent to guess.

Implementation

1. Add fake-clock test and confirm RED.
2. Add the smallest warning state.
3. Reuse the existing activity reset function.
4. Confirm the existing lock function still owns key clearing.
5. Run affected tests.
6. Send the diff to a read-only security reviewer.
7. Record evidence per acceptance criterion.

Release

1. Verify fake-clock behavior automatically.
2. Verify real background-tab behavior in staging.
3. Confirm lock still clears sensitive state.
4. Release with a rollback that disables only the warning UI, not the lock.

This example can be implemented in any language or framework. The reusable asset is the control structure.

14. Failure modes to expect

The reusable lesson

AI agents do not remove the need for engineering discipline. They amplify whatever system surrounds them.

If the system is vague, they produce ambiguity faster. If it has explicit authority, bounded scope, testable criteria, independent review, and evidence-backed release gates, they can help one person cover far more ground without pretending to be a large organization.

For NT², the final boundary is straightforward:

• AI assists with drafts, implementation, verification, and investigation.
• Humans own product decisions, security acceptance, releases, and customer-visible actions.
• Vault plaintext stays on the user’s device and is never sent to AI services.

Open NT² Vault