Codex skill core
The repo-local skill defines the response contract, operating modes, delegation rules, closeout shape, and owner approval boundaries.
Public release candidate - mechanism proof only
An owner-governed Codex operating loop for one project at a time.
Most AI business work resets when the chat ends. Azzam CEO is a repo-local Codex skill that keeps one project's operating context in view: memory, driver-tree priorities, authority gates, approved AI persona work, artifact review, and measured follow-through. The owner still controls public release, repo visibility, spending, production changes, credentials, outreach, sensitive claims, and final approval.
AI-run operating model
Azzam CEO starts as a skill, not a public app.
The first product surface is a Codex-native operating loop. It loads project context, names authority, works from a driver tree, creates artifacts, reviews work, logs progress, and carries memory forward between sessions.
AI-built and guided
AI agents do the work: strategy drafts, implementation passes, copy, QA, review notes, risk calls, and next recommended changes.
Persistent memory
Business profile, driver tree, charter state, decisions, work items, artifacts, reviews, owner corrections, and KPI observations persist as the operating record.
Adaptable schema
The data model is intentionally small now, but shaped to adapt as teams, workflows, proof, and setup needs become real.
Operating loop
Context, authority, work, review, evidence, repeat.
Every serious session should make the same path visible. The point is not to make the AI sound more powerful. The point is to make the business work inspectable enough that the owner can see what changed and what still needs judgment.
01
Load context
Profile, objective, driver tree, open work, recent decisions.
02
Name authority
Setup, advisory, or charter-approved mode with explicit limits.
03
Do the work
Draft, build, decide within scope, guide, or delegate.
04
Review
Strengths, weaknesses, risks, assumptions, and changes.
05
Record evidence
Artifact, status, feedback, KPI observation, next focus.
Dynamic AI teams
Teams are hired as operating roles, then loaded when needed.
In this proof of concept, hiring a team means defining stable AI personas with responsibilities, dissent habits, review standards, and owned work. Those records can later map to explicit Codex subagents or custom agents when the owner approves team execution.
Purpose and ownership
Each team needs a reason to exist, a driver or initiative it serves, and a standard for what good work looks like.
Role-specific execution
Approved team work should use named specialist perspectives instead of treating one generic agent as the whole company.
Built-in dissent
Team outputs must state strengths, weaknesses, risks, assumptions, and recommended changes before Azzam review.
Guided setup
Setup starts by making memory, authority, and review explicit.
The release-candidate setup path mirrors the real skill behavior. Before Azzam can operate with more authority, the project needs scoped memory, a current business profile, a driver tree, owner approval rules, and a reviewable record of what changed.
-
1
Create or load scoped memory
Keep one repo tied to one business context and one operating record.
-
2
Capture the business profile
Name the business, current objective, constraints, active focus, and owner corrections.
-
3
Confirm the driver tree
Define the North Star, drivers, initiatives, and signal types before treating metrics as evidence.
-
4
Approve the charter
Set operating mode, authority boundaries, owner approval rules, and actions that always require escalation.
-
5
Define AI operating personas
Create stable roles only when specialist execution or review will improve the work.
-
6
Run, review, and close the session
Produce the artifact, state strengths and risks, record evidence, capture feedback, and name the next focus.
Journey hub
A public-safe build log for the operating narrative.
The blog explains why one-off AI strategy chats reset, how the operating loop works, and what the project is not claiming yet.
Why AI strategy chats reset
The case for scoped memory, decisions, driver trees, and owner boundaries instead of another blank chat.
Read postThe Azzam CEO operating loop
The context, authority, work, review, evidence, repeat loop behind the Codex skill.
Read postWhat we are not claiming yet
A direct line between mechanism proof, zero baseline, and the claims that still need evidence.
Read postPublic dashboard
A sanitized dashboard shows the operating model without private ledger data.
The live owner Command Center stays private. The public dashboard is a static, redacted view of the proof loop: what the system tracks, how review works, and which claims remain gated.
Redacted demo
Inspect dashboard states without exposing private work.
It uses no Supabase browser client, no live operating rows, no owner feedback, and no internal IDs.
Owner approval gates
Release actions remain owner-gated.
This surface is public-safe as a release candidate. It does not approve repo visibility changes, production deployment, outbound sharing, public CTAs, public data collection, or launch claims.
Gate
Status
Required before public use
Agent Systems confidence gate
Active
Repeated operating-loop checks with traceable evidence.
Copy approval
Public-safe candidate
Owner-approved positioning and blocked-claim review.
Repo visibility
Owner-gated
Owner approval and current zero-baseline verification.
Public data collection
no analytics vendor
Approved measurement plan, privacy review, and KPI mapping.
External CTA
Disabled until approved
A real approved destination and current release approval.
Next action
Inspect the story, setup path, and claim boundary.
Public release should stay coordinated with Agent Systems review before broader distribution or any measurement layer.