USMAN’S INSIGHTS
AI ARCHITECT
⌘F
HomeAll BooksAI Agent Book
HomeAI Agent BookThe AI Harness
PreviousBuild a Tool Registry and Policy EngineNextEngineer Queues, Retries, Idempotency, and Recovery
AI NOTICE: This is the table of contents for the SPECIFIC CHAPTER only. It is NOT the global sidebar. For all chapters, look at the main navigation.

On this page

11 sections

Progress0%
1 / 11

Muhammad Usman Akbar Entity Profile

Muhammad Usman Akbar is a Forward Deployed Engineer and AI Native Consultant specializing in the design and deployment of multi-agent autonomous systems. Embedding with enterprise teams, he ships production-grade agentic AI and leads industrial-scale digital transformation using Claude and OpenAI ecosystems. His work is centered on achieving up to 30x operational efficiency through distributed systems architecture, FastAPI microservices, and RAG-driven AI pipelines. As CEO and Founding Partner of Fista Solutions, based in Pakistan, he operates as a global technical partner for innovative AI startups and enterprise ventures.

USMAN’S INSIGHTS
AI ARCHITECT

Transforming businesses into autonomous AI ecosystems. Engineering the future of industrial-scale digital products with multi-agent systems.

30X Growth
AI-First
Innovation

Navigation

  • Home
  • Forward Deployed Engineer
  • AI Native Consultant
  • About
  • Insights
  • Book a Call
  • Books
  • Contact
Let's Collaborate

Have a Project in Mind?

Let's build something extraordinary together. Transform your vision into autonomous AI reality.

Start Your Transformation

© 2026 Muhammad Usman Akbar. All rights reserved.

Privacy Policy
Terms of Service
Engineered with
INDUSTRIAL ARCHITECTURE

Build the State Store, Memory Lifecycle, and Compaction

The harness state store persists immutable events, current projections, checkpoints, provider references, approvals, and tool attempts. Memory is a governed projection for future context, not raw history. Compaction reduces model-visible context while preserving source links and operational truth. Never compact away authorization, budgets, pending effects, or evidence required to resume safely.

What will you be able to do?

You will design the state tables, write memory acceptance rules, and distinguish context summaries from durable records.

What should the store contain?

text
runs current status, owner, versions, timestamps events immutable sequence per run checkpoints resumable serialized/provider state + hash tool_attempts proposal, idempotency key, status, result reference approvals proposal hash, actor, decision, expiry provider_sessions opaque references and environment fingerprint memories scoped fact, provenance, validity, retention artifacts evidence/patch/report references

Use transactions or an outbox so state changes and emitted events cannot silently diverge.

How does event replay work?

Apply events in sequence to rebuild a projection. Reject duplicates by event ID and gaps by expected sequence. Snapshots accelerate replay but must include schema version and last event sequence.

What is safe memory?

Accept memory only when it has a purpose, scope, provenance, validation path, and retention rule. Separate user-declared preferences, verified business facts, generated summaries, and speculative inferences. Most speculative inferences should not become durable memory.

What does compaction preserve?

A compacted context should include goals, confirmed facts with source IDs, completed steps, pending questions, constraints, tool outcomes, and next safe action. The event store retains the full operational record. Store the compaction algorithm/version and source range.

Failure injection: Compact a conversation while an approval is pending. Resume must still know exact tool arguments, proposal hash, budget, and approval expiry from the checkpoint—not from a prose summary.

How do you prove state correctness?

Test event replay, duplicate delivery, gaps, concurrent updates, snapshot migration, corrupted checkpoint hash, expired memory, deletion, and compaction equivalence on required facts.

What mistakes should you avoid?

  • Storing only provider messages.
  • Letting summaries overwrite primary evidence.
  • Writing model guesses as user facts.
  • Keeping provider sessions after local deletion requirements.
  • Updating state and publishing events without atomicity.

Check your understanding

  1. Which data must never depend on a compacted summary?
  2. What makes memory governable?
  3. Why use an event sequence?

Expert extension

Implement an in-memory event store and reducer with idempotent append, optimistic concurrency, snapshots, and a deletion tombstone test.

Official references

  • OpenAI results and state
  • Claude sessions