AIRCHOR FOR AGENCIES
Understand the client project before uncertainty becomes delivery risk.
Airchor is designed to help agencies turn new briefs and inherited software into one Project Model, a bounded delivery plan, visible work and a reviewable evidence trail.
- ClientContext and decisionsInput
- AgencyScope and coordinated workBoundary
- ReviewEvidence and acceptanceDecision
- HandoffOwnership and continuationOutcome
Client context is often fragmented before implementation starts.
A brief may omit technical constraints. An inherited application may arrive without reliable documentation. Decisions may be scattered across email, chats, tickets and provider dashboards.
Without a shared project state, scope, pricing and delivery depend on assumptions that surface too late.
Use one delivery system across both project origins.
A new client project can begin from product intent and constraints. An inherited project can begin from supplied evidence, observed behaviour and the available technical context.
Airchor brings both into one Project Model so that the agency, client and delivery team can review the same accepted project state.
Know what supports the assessment and what remains unverified.
The Control Plane direction treats source material, extracted observations, accepted facts and unresolved conflicts as separate objects. This helps an agency explain the basis of its recommendation without presenting incomplete evidence as certainty.
The unified Source Inbox and repository-aware understanding are in active development and roadmap stages; current assessment workflows rely on supplied project context.
- 01Received
- 02Classified
- 03Reviewed
- 04Linked
- 05Project Model
Sources remain separate from accepted facts; unified repository-aware intake is not shown as available today.
CONTROL PLANE WORK ITEM
Deliver one approved change
- Scope
- One bounded result
- Coordinator
- Airchor Control Plane
- State
- Waiting for coordinated work
- Dependency
- Approved Build Specification
- Evidence
- Task, human and provider records
- Next action
- Verify the complete result
AGENT TASK · SPECIALISED EXECUTION OBJECT
Implement the approved technical scope
- State
- Awaiting verification
- Current step
- Evidence handoff
- Completed
- Plan followed · Change reported
- Pending
- Independent verification
- Evidence
- Changed files and command results
Review the exact result
- Actor
- Reviewer
- Mode
- Assisted
- Instruction
- Compare the result with the approved scope.
- Evidence
- Recorded review decision
- Resumes
- Verification and Preview path
EXTERNAL-SYSTEM STEP
External provider
- Responsible actor
- External provider
- Required input
- Exact approved operation
- Returned evidence
- Correlated provider result
- State
- Waiting
- Boundary
- Outside Airchor execution
- AI agentPerform bounded approved workTask evidence
- HumanApprove, review or provide evidenceRecorded decision
- External systemPerform provider-controlled operationCorrelated result
Human confirmation, provider completion and independently verified completion remain separate states.
INDEPENDENT VERIFICATION RECORD
Approved acceptance criteria
- Method
- Independent checks and review
- Evidence
- Linked, attributable records
- Result
- Passed, failed, incomplete or blocked
- Limitations
- Only the declared scope
- Verifier
- Separate verification path
Turn discovery into a versioned Build Specification.
A Build Specification should identify the agreed outcome, included and excluded work, acceptance criteria, dependencies, client responsibilities, provider boundaries and evidence required for review.
This creates a clearer basis for scope, price, approval and change control than an open-ended promise to “continue development.”
Keep every dependency visible before it blocks delivery.
Control Plane Work Items are designed to show who is responsible, whether the work is automated, assisted or manual, what it depends on and what evidence is required.
Client approvals, content decisions, credentials, provider configuration and external reviews become explicit steps rather than informal messages outside the project record.
Connect implementation progress to verification and review.
Agent Tasks and technical work should expose the plan, current step, blockers, changes and evidence. Independent verification and Tested Preview are planned stages that separate execution from the client’s decision to accept or launch the result.
Deliver a project the client can continue to own.
Airchor is being designed around customer-controlled repositories, providers, domains, deployments and project assets. The Project Model and delivery record support handoff, continued work and a repeatable agency process without trapping the project in one chat or provider.