AI practice · Framework design
Agent orchestration
How I organize AI work.
My experience in software projects, commerce and SEO helps me judge what a task needs before AI starts. I designed this operating framework to give each task clear inputs, an owner, permitted changes and an observable result—not just a convincing answer.
From a request
to a result you can trust.
Follow a product-sheet task through the framework.
“Prepare this supplier file for a buyer.”
Start with the right brief.
The agent reads the project entrypoint, the commerce rules and the current task. It knows which file is authoritative and what “ready” means.
“Who is responsible for the final file?”
Give each task an owner.
One commerce specialist owns the result. When authorized, a helper can reconcile identifiers while another checks workbook layout. Their findings return to the same owner.
“Prepare a review copy. Do not publish it.”
Agree on what can change.
The task allows reading records and enriching a workbook. Updating live prices or stock is a different action, so it stays outside this contract.
“Does the result actually meet the brief?”
Review the work, then decide.
The owner checks identifiers, formulas, product images and the saved file. Unmatched items remain visible. The requester reviews the result before the task is accepted.
“What should the next task remember?”
Keep the lesson for next time.
After delivery, useful lessons are kept in operating instructions. The listing-recovery case below shows how a recovery rule helps the next task avoid repeating successful work.
The same five steps are explained below, with real document examples.
What working with Codex looks like.
I organize the work by project and specialist, give the task in a conversation, then review the files and evidence it returns.
The sidebar keeps business areas and their responsible conversations together.
I set the task and its limits. The agent reads the relevant files and reports its progress here.
The output comes back as a concrete file, with checks and any unresolved items alongside it.
Read
Start with the right brief.
Before an agent begins, it reads the project instructions and the saved task. This keeps it from using the wrong files or repeating work.
Read the entrypoint
The project entrypoint identifies the canonical project and the systems it owns.
Load the right knowledge
The role card and knowledge map point to relevant workflows and past decisions.
Resume the actual state
Read the accepted scope, stable checklist, artifacts and next open step.
START_HERE.mdChoose a role card from .agents/ for the task, then read that role's agent-workspaces/<role>/knowledge-map.md.
Project entrypoint · starting or resuming a task
A new conversation should not mean starting over.
This is the onboarding file I give a new or returning agent. It tells the agent which business it is working on, whose instructions to follow and where the previous work was saved.
For a product-listing task, that leads to the marketplace role and its product rules before any spreadsheet is changed.
Assign
Give each task an owner.
I keep specialist conversations for different business areas. One owner brings their work together and remains responsible for the result.
I define the goal
What needs to be done, and what may change.
One owner coordinates
The originating chat assigns work and keeps the whole task together.
Specialists handle their part
Each conversation uses its own instructions and business records.
The result comes back to me
The owner combines the work and its checks. I review and accept the result.
Outcome & authority
Approve the goal and the actions it requires.
One accountable owner
Define the contract, choose the specialist, integrate the evidence and report back.
Storefront & catalog
Shopify, Zoho and marketplace specialists work inside their own system boundaries.
Data & measurement
Sources, populations and calculation rules stay explicit.
Process & skill review
Review reusable lessons and version changes without taking over business delivery.
Existing threads are reused. Messages wait for a safe attention boundary; a busy specialist is not interrupted.
One task owner
The primary agent divides the approved task into independent parts.
Workers run separate checks
One reads the sources, another builds a module, and another checks the result.
The owner brings it together
It integrates the outputs and tests the complete task—not just each part.
I review the finished result
There is one clear handoff for approval.
Own the approved result
Break down independent work, reserve file ownership, then integrate and verify.
Read & reconcile
Inspect sources; return a compact findings file.
Build a bounded part
Edit only the assigned module or artifact.
Check the result
Compare behavior and evidence with the agreed acceptance conditions.
Illustrative split within one task. Parallel agents are used only when authorized; dependent steps stay sequential.
nordstrom-marketplace-agent.mdFill products and offers import files.
Prepare image mapping.
Process error reports.
Nordstrom marketplace chat · product-listing preparation
A listing task goes to the marketplace specialist.
This is how the framework becomes a real assignment: my Nordstrom specialist prepares the listing files, checks product images and resolves submission errors.
The role card gives that conversation a clear job. It returns the files and any unresolved issues to the task owner for review.
Bound
Agree on what can change.
Preparing a file, changing a live product and publishing a website are different tasks. I make that distinction before work starts.
global-red-lines.mdDo not change inventory unless explicitly asked. Inventory is a financial and operations red line.
Nordstrom marketplace chat · listing preparation, not live stock changes
Checking stock is different from changing it.
The global rules set limits for every agent. A request to prepare a listing can include reading stock figures; it does not automatically allow changing those figures in the live system.
The agent can finish the review file while keeping an unrelated stock adjustment outside the task.
Verify
Review the work, then decide.
I inspect the output and its checks, then accept it or request changes. I also record what was delivered, what needed correction and whether the task stayed organized.
Completeness
Was the approved scope delivered and verified?
Correctness
How much substantive correction was needed before acceptance?
Continuity
Did the plan, ownership and state survive the whole task?
Delivery & acceptance rulesReady for your review.
- Prepared listing file
- Checks and missing items included
Awaiting a decision
Delivery review · a product-listing example
Finished is a decision, not a message.
For a listing task, the agent returns the prepared file, its checks and anything still missing. I review the work before accepting it.
If I ask for changes, the same task stays open. Silence is never treated as approval.
Improve
Keep the lesson for next time.
The first four stages deliver a task. This is how I retain useful operating lessons for future work. An interrupted Shopify listing task shows why a clear recovery procedure matters.
Item 4 of 8 · Product listing
Product 04
Eight-product listing task
The connection failed.
The product was already there.
During an eight-product Shopify listing task, a request stopped at the fourth product. Starting again could have created a duplicate.
The product and image already exist.
Product 04
Eight-product listing task
Find out what actually happened.
The agent checked the store again. The product and image existed; the image still needed to be linked to the variant. The task could continue from that point.
Attach the existing image, then verify.
Product 04
Eight-product listing task
Finish only what is missing.
The recovery linked the existing image and completed the listing. The batch finished with eight verified listings and no duplicate creation.
Before another attempt
Applied to the next interrupted operation.
Make the next recovery predictable.
This is the behavior I preserve in my operating instructions: after an uncertain response, check the live state, skip successful steps and verify the remainder. The next task starts with that rule.
16 September 2026 · Real task, reconstructed interface