Companion guide for Danial Hasan's talk at the AI Agent-Building Workshop at TMU on August 10, 2026.
Connect with Danial:
- LinkedIn: https://linkedin.com/in/dhasandev
- X: https://x.com/dhasandev
- Define a goal that names the result, proof, scope, and stop conditions.
- Give the agent signals from the real work.
- Organize the work as claims that evidence can support, reject, revise, or hold.
The case study behind this talk used one durable goal and a dependency graph. The goal stayed active for several days. The agent worked independently between decision gates. People corrected some gates.
This graph shows the full program structure used by the controller. Each capability node states an area that the system must prove. Each arrow shows a dependency. Each gate controls when the next area of work can start or when a person must make a decision.
---
config:
layout: elk
flowchart:
curve: step
nodeSpacing: 50
rankSpacing: 70
elk:
mergeEdges: false
nodePlacementStrategy: LINEAR_SEGMENTS
considerModelOrder: NODES_AND_EDGES
---
flowchart TB
G0["G0 · Portable foundation admission"]
subgraph Portable["Portable agent system"]
direction TB
B15["B15 · Safety, authority, and runtime control"]
B17["B17 · Evidence and replay"]
B1["B1 · Agent execution"]
B2["B2 · Repository and file operations"]
B3["B3 · Language and code intelligence"]
B4["B4 · Terminal and process control"]
B6["B6 · Tool disclosure"]
B7["B7 · Skills, rules, and extensions"]
B8["B8 · Typed resource access"]
B9["B9 · Hierarchical work"]
B5["B5 · Persistent computation"]
B13["B13 · Host interfaces and embedding"]
B14["B14 · Provider and model control"]
RP["Remote-host proof\nOnly when the claim requires it"]
B15 --> B1
B17 --> B1
B15 --> B2
B17 --> B2
B15 --> B3
B17 --> B3
B15 --> B4
B17 --> B4
B15 --> B6
B17 --> B6
B6 --> B7
B6 --> B8
B1 --> B9
B6 --> B9
B15 --> B9
B17 --> B9
B4 --> B5
B8 --> B5
B8 --> B13
B15 --> B13
B17 --> B13
B15 --> B14
B17 --> B14
B13 --> RP
B15 --> RP
B17 --> RP
end
subgraph External["External collaboration"]
direction TB
B12["B12 · GitHub, review, and collaboration"]
B2 --> B12
B6 --> B12
B8 --> B12
B15 --> B12
B17 --> B12
end
G1["G1 · Product control admission\nImport the package; do not fork it"]
subgraph Product["Product integration"]
direction TB
B16["B16 · Missions, tasks, and durable control"]
B10["B10 · Context, memory, and continuity"]
B11["B11 · Browser, computer, web, and media"]
B16 --> B10
B8 --> B10
B15 --> B10
B17 --> B10
B4 --> B11
B6 --> B11
B8 --> B11
B15 --> B11
B17 --> B11
end
G2["G2 · Evaluation admission\nRequired capability claims have proof"]
B18["B18 · Held-out evaluation and feedback descent"]
BENCH["Comparative benchmarks\nOne frozen protocol"]
G3["G3 · Human decision\nPromote, revise, or reject"]
G4["G4 · Consumer-host release\nPin the package and prove the journey"]
G0 --> B15
G0 --> B17
G0 --> B2
G0 --> B3
G0 --> B4
G0 --> B6
G0 --> G1
G1 --> B16
G1 --> B11
B10 --> G2
B11 --> G2
B12 --> G2
B13 --> G2
B14 --> G2
B16 --> G2
G2 --> B18
B18 --> BENCH
BENCH --> G3
G3 --> G4
The graph prevents work from starting before its dependencies are ready. It also prevents a small proof from becoming a large claim.
Use this prompt with your agent:
Audit my current goal.
1. State the concrete result that must be true.
2. State the evidence that proves the result.
3. State a binary or quantitative completion threshold.
4. State what is in scope and out of scope.
5. State the conditions that require a human decision.
6. Identify activity statements that do not describe a result.
7. Rewrite the goal so that the agent cannot claim completion from effort alone.
Return:
- the current weakness;
- the revised goal;
- the proof checklist;
- the stop conditions.
Use this prompt with your agent:
Audit the environment for this agent task.
Inspect the tools, files, tests, logs, browser state, user feedback, budgets,
authority rules, review steps, and completion records that the agent can see.
For each item, classify it as:
- a work signal;
- a control signal;
- a completion signal;
- missing;
- misleading.
Then answer:
1. Can the agent observe the real effect of its work?
2. Can the agent distinguish a passing test from a useful result?
3. Can the agent detect work outside its authority?
4. Can the agent detect false completion?
5. Can the agent spend time or money without improving the result?
6. What is the smallest environment change that will prevent the most rework?
Return a table with: signal, current source, gap, risk, and recommended change.
Claim-driven engineering is the operating model used in this case study. It is a synthesis, not a published standard.
- A claim states what must be true.
- Evidence can support or reject the claim.
- A task exists to implement, test, support, reject, revise, or hold a claim.
- A dependency states which claims must pass before another claim can start.
- A gate reserves a decision for a person or another authority.
- A non-claim states what the evidence does not prove.
This model combines ideas from assurance cases, scientific hypothesis tests, requirements traceability, provenance, and dependency scheduling.
CLAIM
-> define the falsifier
-> identify dependencies and authority
-> make the smallest change
-> collect evidence
-> support, reject, revise, or hold
-> admit the next claim
Convert this project into a claim graph.
1. State the main outcome claim.
2. Split it into the smallest claims that can be tested independently.
3. For each claim, state:
- required evidence;
- falsifier;
- dependencies;
- owner or authority;
- non-claims;
- current state: proposed, active, supported, rejected, revised, or held.
4. Find tasks that do not change any claim.
5. Find claims with no proof method.
6. Find proof that is being used to support a larger claim than it can prove.
7. Select the next allowed claim that gives the most useful progress.
Return a Mermaid dependency graph and a claim table.
Do not call the project complete while one required claim is unsupported or held.
Audit this loop as an optimization system.
1. What result does the loop reward in practice?
2. Which proxy measures can the agent improve without improving the user result?
3. How much work is implementation, and how much is planning, reporting,
orchestration, or other control work?
4. Which cycle produced the last visible user result?
5. What evidence would show that the loop is busy but ineffective?
6. Add one stop rule for cost, one for repeated failure, and one for human authority.
Recommend the smallest change that makes the real result easier to optimize.
- OpenAI's
define-goalskill provides the first-layer method: result, proof, bounds, and stop conditions. - Goal Structuring Notation is an established method for connecting assurance claims, arguments, and evidence.
- NASA requirements guidance connects each requirement to its source and verification method.
- W3C PROV connects entities, activities, agents, and derivation chains.
- Claim-driven engineering is our synthesis of these ideas for human-and-agent work.
- This case study proves one operating method in one real program. It does not prove that every long-running agent will finish correctly.
Public sources: