Creasura Blog · For CTOs
What happens when the agent is wrong?
Inside Creasura’s proposed business operating protocol, from the first customer workflow to four connected processes
A customer message is in flight. An engineer changes the configuration on which the plan depends. A manager revokes the permission to send further messages. Before the delivery result is recorded, the worker restarts.
Maya, the COO, opens a fresh conversation in ChatGPT.
What happened with Harbor? Can we continue onboarding?
Alex, Northstar’s CTO, asks a different question.
Which state do you trust, which actions can still run, and how do you know?
That is the question we want Creasura to answer well.
A useful business agent must remain understandable when execution is interrupted, evidence changes, and people disagree. Its record of the work must survive the conversation. Its authority must come from enforceable policy. Its claims of completion must refer to something that actually happened.
To show how we approach that problem, we will follow Maya and Alex from their first discovery session through four connected workflows: onboarding, issue resolution, product improvement, and renewal readiness. At each step, Alex puts a different part of the design under pressure.
Who does what
ChatGPT Proposes
Interpret, propose, explain, and request operations
CAOP boundary
Define operation schemas, results, versions, and failure semantics
Creasura kernel Decides and records
Persist work, enforce authorization, maintain revisions, and evaluate dependencies
Execution extensions
Run authorized workflows, interact with providers, reconcile uncertain outcomes, and verify defined results
People Owners and approvers
Own business goals, resolve judgment calls, and authorize consequential decisions
Six things that can’t go wrong silently
- Statements are not decisions
the system preserves the distinction between what was said, what is supported, and what the organization has adopted.
- Configuration cannot grant itself permission
model output and profile text cannot create their own authority.
- Human review can become stale
stale approval cannot silently overwrite newer operating state.
- Uncertainty is a legitimate state
a pinned workflow configuration never exempts a privileged action from current permission checks.
- Changed evidence has a bounded effect
a source revision cannot silently rewrite downstream decisions or erase their history.
- Learning needs a promotion boundary
operational experience cannot silently promote itself into production authority.
Chapter 1
The architecture behind the conversation
Maya works through ChatGPT. ChatGPT asks questions, interprets returned evidence, proposes changes, and invokes tools. Creasura maintains the work records and decides whether those requests are permitted and valid.
CAOP, the proposed Creasura Agentic Operating System Protocol, is the application contract between that reasoning experience and the work system. It describes operations such as retrieving context, proposing a decision, recording a commitment, activating a profile, or inspecting a run. MCP supplies the tool integration mechanism. CAOP supplies the business semantics implemented by Creasura.
The examples below show compact CAOP operation payloads. They omit MCP envelopes and transport details to keep the important state transitions visible. Authentication comes from the connection; a model cannot select its authority by adding a user or tenant field to the request.
| Layer | Responsibility |
|---|---|
| ChatGPT | Interpret, propose, explain, and request operations |
| CAOP boundary | Define operation schemas, results, versions, and failure semantics |
| Creasura kernel | Persist work, enforce authorization, maintain revisions, and evaluate dependencies |
| Execution extensions | Run authorized workflows, interact with providers, reconcile uncertain outcomes, and verify defined results |
| People | Own business goals, resolve judgment calls, and authorize consequential decisions |
The initial kernel is designed to perform deterministic operations without secondary model calls. That does not make the overall system deterministic: ChatGPT’s interpretation still requires scrutiny. The separation makes it possible to evaluate interpretation quality independently from storage, authorization, and execution correctness.
Next: Chapter 2 · Session one starts with the operating problem ›
Chapter 2 · Engineering challenge 1
Session one starts with the operating problem
We already use AI. But every Monday I still ask three teams which customers are stuck, who owns the blocker, and whether anyone followed up.
Let’s start with the most recent case.
Harbor Distribution. Sales promised a quick implementation. Customer success thought engineering had everything. Engineering was waiting for access.
What would a better outcome look like?
Customers reach production sooner, and my team spends less time chasing people.
Creasura and Northstar begin with selected customer records, approved meeting notes, and a review of how onboarding actually happens. Their assessment exposes different definitions of completion, unclear ownership of cross-team blockers, and missing measures of coordination effort.
You have Maya’s account of what happened. How do you keep that from becoming the official explanation?
Engineering challenge 1 · Statements are not decisions
ChatGPT can extract a plausible explanation from Maya’s words. Creasura must preserve what kind of record it is.
A statement has a source. A proposal has a review state. An adopted decision has an authorized confirmation. Evidence support and freshness are additional dimensions; adoption does not make a claim true.
Behind the scenes · propose_decision · design operation
Illustrative design operation: propose a decision
Request
{
"operation": "propose_decision",
"idempotency_key": "proposal-harbor-completion-01",
"payload": {
"project_id": "harbor-onboarding",
"statement": "Completion requires production success and Lena's acceptance",
"source_refs": ["maya-statement-r1", "lena-note-r2"]
}
}Response
{
"decision_id": "completion-rule",
"revision": 1,
"adoption": "PROPOSED",
"evidence": "UNKNOWN",
"freshness": "CURRENT",
"authorizes_execution": false
}What promotes it?
The required confirmation from an authorized person, tied to the exact proposed decision. Changing the content invalidates that confirmation. A model-generated “approved” field cannot impersonate the person.
- State transition
- an attributed proposal exists. No workflow starts, and no authority changes.
- Invariant
- the system preserves the distinction between what was said, what is supported, and what the organization has adopted.
For Maya, this produces a clearer operating agreement. Lena owns the onboarding outcome. Engineering owns technical validation. The sales director resolves commercial scope. Completion means verified production use and Lena’s acceptance.
Next: Chapter 3 · Session two gives the first workflow explicit authority ›
Chapter 3 · Engineering challenge 2
Session two gives the first workflow explicit authority
The team selects standard customer onboarding as the first pilot. It has recurring volume, an owner, accessible records, and a result worth measuring.
We’ll rehearse the process, define escalation rules, and establish the baseline before activating it.
Can it prepare the customer messages and create the internal tasks?
And what prevents it from deciding that it can send those messages as well?
Engineering challenge 2 · Configuration cannot grant itself permission
Creasura’s profile defines how work should operate: relevant context, owners, review requirements, and workflow preferences. Effective authority also depends on deployment constraints, authenticated scopes, integration permissions, and operation-specific authorization.
Those constraints are intersected. A more permissive profile cannot widen the grants beneath it.
Behind the scenes · evaluate_action_policy · extension
Illustrative extension: preview an action policy
Request
{
"operation": "evaluate_action_policy",
"payload": {
"action": "send_customer_message",
"project_id": "harbor-onboarding",
"mode": "PREVIEW"
}
}Response
{
"may_prepare": true,
"may_execute_now": false,
"blockers": [
"CUSTOMER_MESSAGE_APPROVAL_REQUIRED",
"MESSAGING_INTEGRATION_NOT_AUTHORIZED"
],
"action_executed": false
}Even if ChatGPT says the user asked for it?
The server still checks the authenticated actor, current grants, and any required approval. The explanation in the conversation does not override those checks.
- State transition
- none. A policy preview reports what is missing.
- Invariant
- model output and profile text cannot create their own authority.
The team then completes the necessary setup: reviewed sources, actual integrations, explicit escalation conditions, supported execution capabilities, and rehearsals. Profile activation and trigger activation are separate operations. A saved schedule declaration is not an active scheduler.
The first live workflow can now begin within a known boundary.
Next: Chapter 4 · Session three exposes concurrent changes ›
Chapter 4 · Engineering challenge 3
Session three exposes concurrent changes
Maya reviews the proposed onboarding policy while Lena corrects its escalation owner. Maya then approves the version she had been reading.
Does the latest conversation win?
The request must match the current binding version. Otherwise it fails before activation.
Engineering challenge 3 · Human review can become stale
Approval and concurrency checks solve different problems. Approval establishes who accepted a specific action. Version checks establish whether the relevant state is still the state they reviewed.
Behind the scenes · activate_profile · design operationRejected · VERSION_CONFLICT
Illustrative design operation: activate a profile
Request
{
"operation": "activate_profile",
"idempotency_key": "activate-onboarding-v12",
"expected_binding_version": 7,
"payload": {
"candidate_version": 12,
"approval_reference": "approval-profile-v12"
}
}Response
{
"error": "VERSION_CONFLICT",
"expected_binding_version": 7,
"current_binding_version": 8,
"activation_applied": false,
"next_action": "retrieve_current_binding_and_reconcile"
}What would I see?
That Lena changed the policy after your preview, which change matters, and what needs reconciliation. We would not quietly retry your old proposal against the new version.
- State transition
- none from the rejected request. The current binding remains intact.
- Invariant
- stale approval cannot silently overwrite newer operating state.
This is also why acknowledged writes need a clear commit boundary. In the proposed kernel, the record update, revision information, idempotency result, audit event, and outbox event commit together. A lost response can be retried with the same key and payload, subject to current authorization, without creating another internal mutation. A reused key with different content fails.
That guarantee is scoped to the kernel transaction. An external provider needs its own execution strategy.
Next: Chapter 5 · Session four asks what happened after the crash ›
Chapter 5 · Engineering challenge 4
Session four asks what happened after the crash
Harbor’s onboarding advances. Lena approves a prepared access request. The execution service sends it, but the response times out. The worker restarts before the outcome is known. Meanwhile, Northstar revokes messaging access.
We have reached the opening scene.
What happened with Harbor? Can we continue onboarding?
Which state do you trust, which actions can still run, and how do you know?
Engineering challenge 4 · Uncertainty is a legitimate state
A local transaction cannot make an external email send atomic. The provider may have accepted the message even if Creasura did not receive a receipt.
The correct response is to preserve uncertainty, reconcile where possible, and check current permission before another privileged action.
Behind the scenes · get_run · design operation
Illustrative design operation: inspect a run, with extended action diagnostics
Request
{
"operation": "get_run",
"run_id": "harbor-run-01"
}Response
{
"run_id": "harbor-run-01",
"status": "WAITING_FOR_APPROVAL",
"profile_version": 2,
"last_action": {
"action_id": "access-request-01",
"delivery_state": "UNKNOWN",
"reconciliation_state": "PENDING"
},
"current_policy": {
"messaging_write": "REVOKED"
},
"automatic_resend_allowed": false
}The workflow-level status and action-level uncertainty are separate. A more complete implementation would define the precise suspension and reconciliation states in its execution contract.
The approved request may have been accepted by the provider. We do not yet have confirmation. Messaging permission is now revoked, so we will not resend it. Reconciliation can continue only if the necessary read permission remains available; otherwise it requires an authorized operator.
What if reconciliation proves it was sent before the revocation?
We record that result. Revoking permission prevents future authorized sends; it cannot recall a message already accepted by the provider.
- State transition
- an uncertain action becomes confirmed only when evidence supports that transition. Revocation changes which further actions are permitted.
- Invariant
- a pinned workflow configuration never exempts a privileged action from current permission checks.
Provider idempotency and receipt lookup can reduce duplicate risk. Where those facilities are missing, the workflow needs a more conservative recovery procedure. The design does not promise exactly-once external execution.
When Maya returns in a new ChatGPT conversation, Creasura supplies the current run, evidence, and blockers. ChatGPT explains those records. It does not need to reconstruct the outcome from yesterday’s conversational confidence.
Next: Chapter 6 · The first results review separates activity from value ›
Chapter 6
The first results review separates activity from value
After a sufficient set of comparable cases, Maya asks whether onboarding improved.
We have more structured work. Are customers benefiting?
We need to compare verified time to value, employee effort, waiting time, rework, and total cost. Review, correction, and manual recovery effort all count.
Can you derive employee effort from the audit log?
Not reliably. The log shows operations. Effort needs an agreed measurement method. That is a separate instrumentation requirement.
The review also distinguishes an engineering task from a customer outcome. Technical validation can finish while production evidence or customer acceptance is still missing. The workflow’s completion gate must inspect the agreed evidence, with human judgment where necessary.
Northstar expands only when the first pilot demonstrates a useful result and exposes manageable failure modes. The next workflow is customer issue resolution.
Next: Chapter 7 · Workflow two tests whether context actually carries across teams ›
Chapter 7 · Engineering challenge 5
Workflow two tests whether context actually carries across teams
Harbor reports a failed inventory sync after onboarding.
Support is asking questions we already answered during implementation.
We can link the issue to Harbor’s authorized onboarding context, identify missing diagnostics, and track recovery through verification.
Are you copying the old summary into a new agent?
We retrieve the relevant records and their revisions. Support receives the information it is allowed to access. The new workflow has its own owner, permissions, and resolution criteria.
The issue can become a dependency of an active onboarding. The customer communication owner is explicit. A closed engineering ticket triggers verification rather than automatically certifying customer recovery.
Then an engineer discovers that Harbor’s actual configuration differs from the version used to verify the earlier recovery.
Show me every conclusion that depended on the old configuration. Which ones need review, and which ones still have independent support?
Engineering challenge 5 · Changed evidence has a bounded effect
The proposed dependency model binds consumers to explicit prerequisite revisions. When an upstream revision changes, Creasura can identify the affected consumers and record why they need review.
It must also preserve alternatives. If a conclusion has independent acceptable support, the loss of one supporting path does not automatically invalidate the other.
Behind the scenes · inspect_dependency_impact · extension
Illustrative extension: inspect dependency impact after an authorized source update
Request
{
"operation": "inspect_dependency_impact",
"source_id": "harbor-integration-config",
"previous_revision": 3,
"current_revision": 4
}Response
{
"review_required": [
{
"record_id": "sync-recovery-verification",
"reason": "bound to configuration revision 3"
},
{
"record_id": "renewal-technical-health-claim",
"reason": "depends on sync-recovery-verification"
}
],
"independent_support_retained": [
{
"record_id": "initial-onboarding-acceptance",
"support_refs": [
"historical-production-event",
"customer-acceptance-record"
]
}
],
"truth_reversal_inferred": false,
"automatic_record_rewrites": []
}Does this mean onboarding was never successful?
No. The original milestone can remain a supported historical event. The current recovery claim needs rechecking against the changed configuration. We keep those claims and their time scopes separate.
And do all workflows stop?
Only actions whose preconditions or policy require the affected evidence should pause. A review marker is not a universal stop command. The workflow must define what that marker means for its execution.
- State transition
- affected records receive explicit review status and reason references. Historical acceptance and unaffected support remain visible.
- Invariant
- a source revision cannot silently rewrite downstream decisions or erase their history.
The propagation itself must be bounded and atomic within the supported mutation scope. The proposed design rejects an oversized update before commit rather than claiming success after only part of the affected graph was processed. Large changes need a separately designed migration or staged-update procedure.
This is where connected workflows can become valuable infrastructure. The system gives engineers a concrete answer to “what depends on this?” while giving business owners an understandable account of what needs attention.
Next: Chapter 8 · Workflow three tests whether learning can change production safely ›
Chapter 8 · Engineering challenge 6
Workflow three tests whether learning can change production safely
Several reviewed issues suggest that customers discover missing access permissions too late. ChatGPT helps assemble the evidence and propose an earlier access check.
Can we turn that into an improvement we actually follow through on?
Product can review the proposal, engineering can deliver the approved change, and we can evaluate whether it reduces late permission failures.
At what point does the agent update the onboarding procedure?
Engineering challenge 6 · Learning needs a promotion boundary
A pattern produces a candidate procedure. It does not directly modify the active one.
Northstar reviews the supporting cases, tests representative and exception scenarios, and stages the change. The evaluation includes customer confusion, failure rates, employee effort, and integration differences—not just whether the new check runs successfully.
Behind the scenes · evaluate_procedure_candidate · extension
Illustrative extension: evaluate a procedure candidate
Request
{
"operation": "evaluate_procedure_candidate",
"candidate_id": "early-access-check-v3",
"baseline_version": 2,
"evaluation_set": "standard-integration-cases-r5"
}Response
{
"candidate_id": "early-access-check-v3",
"evaluation_state": "REVIEW_REQUIRED",
"evaluation_artifact": "evaluation-early-access-r1",
"production_activation": false,
"required_decisions": [
"owner_acceptance",
"rollout_scope",
"rollback_conditions"
]
}The example deliberately contains no invented success rate. The evaluation artifact must hold the actual results before a reviewer makes the promotion decision.
What happens to customers already in progress?
Existing runs retain their pinned procedure and configuration. An explicit migration policy would be needed to move them. New runs use the newly activated version. Current permission revocations still apply to both.
If the new version causes problems?
We can activate the prior compatible version for future work and preserve the rollout history. That does not undo emails sent or product changes already deployed. Those need their own recovery procedures.
- State transition
- candidate, evaluated candidate, approved version, and active binding are distinct states.
- Invariant
- operational experience cannot silently promote itself into production authority.
Northstar now has a controlled improvement cycle: observe a problem, propose a change, evaluate it, approve a bounded rollout, measure the effect, and retain or revise it.
Next: Chapter 9 · Workflow four tests the quality of the business conclusion ›
Chapter 9
Workflow four tests the quality of the business conclusion
Harbor’s renewal approaches. The account owner needs a coherent account of what Northstar promised and delivered.
Prepare the renewal review without asking three teams to reconstruct Harbor’s history.
The integration milestone is verified. The sync recovery claim requires review against the updated configuration. The access improvement has a recorded rollout. We still lack confirmation that Harbor’s purchasing team achieved its original planning objective.
So the briefing includes unknowns?
Yes. A functioning integration does not establish the customer’s business outcome. A review-required claim should not appear as settled evidence in an executive summary.
The renewal workflow draws on the previous three workflows, subject to access controls. It adds its own account owner, trigger, commitments, and completion requirements. ChatGPT can explain the evidence and prepare options. Commercial actions remain subject to their own authority.
The immediate value is measurable through preparation effort, unresolved commitments found early, and completion of agreed account actions. Retention requires a longer observation window and a defensible comparison before claiming an effect.
Four workflows now share business context without sharing unrestricted permissions. They retain their own outcomes while connecting the evidence and dependencies that cross team boundaries.
Next: Chapter 10 · What Alex would require before trusting the system ›
Chapter 10
What Alex would require before trusting the system
The design is coherent. What evidence would convince me the implementation delivers it?
We would put an acceptance report beside the architecture. This article supplies proposed criteria; it does not claim these tests have passed.
| Property | Test | Evidence to publish |
|---|---|---|
| Acknowledged-write durability | Kill the process at selected points before and after commit | Committed records, revisions, and replay results after restart |
| Internal deduplication | Repeat identical commands, then reuse a key with different content | One mutation for an authorized identical replay; explicit conflict for changed content |
| Concurrent updates | Submit conflicting edits from the same starting version | One accepted transition and a visible conflict, without silent overwrite |
| Approval integrity | Change approved content, expire approval, and revoke permission | Rejection at the appropriate gate with no unauthorized side effect |
| External uncertainty | Simulate provider acceptance followed by timeout | Unknown state, reconciliation evidence, and bounded retry behavior |
| Dependency correctness | Change prerequisites with alternative support paths | Correct review propagation while preserving valid independent support |
| Bounded mutation | Exceed the supported affected-subgraph limit | Rejection before partial state is committed |
| Workflow completion | Finish a task while withholding required outcome evidence | No unsupported completed outcome |
| Isolation | Attempt cross-workspace retrieval and mutation | Denial without record or metadata leakage |
| Procedure promotion | Fail evaluation, activate a reviewed version, then roll back | Explicit versions, scope, decisions, and recovery history |
Performance needs equally specific reporting: dataset size, dependency density, affected-subgraph size, warm and cold latency, concurrent readers, write contention, and failure conditions. A latency number without its workload tells Alex little about production suitability.
Operational reporting should disclose backup recovery limits and restore results. A design that survives an ordinary process restart has not thereby established resilience to disk loss or regional failure.
For Maya and the VP of Engineering, the acceptance report needs a second half.
| Business question | Measurement needed |
|---|---|
| Did coordination effort fall? | Human work including approvals, corrections, and manual recovery |
| Did customers reach value sooner? | Verified completion time with comparable case complexity |
| Did the second workflow reuse the first? | Setup effort, reused configuration, new code, and integration work |
| Did connections reduce handoff failures? | Repeated discovery, waiting time, and failed or reopened handoffs |
| Did the product change help? | Exposure, comparison method, outcome quality, and adverse effects |
| Was it economical? | Technology, implementation, maintenance, and human effort per verified outcome |
These measurements distinguish a compelling demonstration from a repeatable operating capability.
Chapter 11
Where the implementation begins
The proposed initial release focuses on authenticated work continuity: source records, reviewed decisions, commitments, revision history, profiles, dependency diagnostics, and sourced context for a fresh conversation.
Background workers, event adapters, external-action reconciliation, business verifiers, and measurement services extend that foundation. They are requirements of the complete journey described here, not capabilities created merely by exposing an MCP endpoint.
The first pilot should prove a narrow vertical slice: an authorized source becomes a reviewed decision and commitment; a later change produces the right review diagnostics; a fresh session resumes the correct state. The next slice adds one bounded execution path and verifies it under failure.
What would make the fourth workflow easier than the first?
Reusing identity, records, evidence relationships, configuration resolution, authorization, revision checks, and execution contracts. The domain-specific workflow still needs its own decisions and verifier. We would measure how much work that reuse actually saves.
And what changes for me?
You can ask about progress and receive an answer grounded in current work. You can inspect what needs your judgment. When something changes, you can see the affected commitments. When we propose an improvement, you can review the evidence and its measured result.
The architecture earns its place when those conversations become dependable under the conditions real businesses encounter: incomplete knowledge, interrupted execution, changing authority, and competing decisions.
That is what we want Alex to inspect—and what we want Maya to be able to rely on.
Further reading
- Becoming AI native: a customer journey: the business leader’s original journey.
- The full journey, all 91 turns and every trace: responsibilities and state changes across all 91 turns; illustrative MCP request and response envelopes, setup checkpoints, and failure branches.
- The CAOP v0.1 specification: the proposed Creasura Agentic Operating System Protocol.
Creasura Business is coming soon.
Your first session can begin with one process.
Join the Interest List The CAOP v0.1 specification ›