AIYINGFrom AI Awareness to Accomplishment
Showing posts with label LangGraph. Show all posts
Showing posts with label LangGraph. Show all posts

Friday, November 13, 2026

AI Engineering Active Concepts #010 — Agent Orchestration: Designing Reliable Multi-Step AI Workflows

AI ENGINEERING — ACTIVE CONCEPTS & PRACTICES | #010

Agent Orchestration: Designing Reliable Multi-Step AI Workflows



Chapter 2: Engineering AI Applications and Agents

AIYING — Accomplishing with AI

The Big Idea: Agent orchestration coordinates the sequence, dependencies, tools, decisions, state, and controls required to complete multi-step AI tasks.

An individual model response may be useful. An orchestrated workflow must deliver a verifiable outcome.

Engineering question: How do we make an AI workflow reliable when it involves multiple steps, external systems, failures, and human approvals?

Contents

  1. Why Agent Orchestration Matters
  2. UNDERSTAND — The Concept
  3. CONNECT — AI Engineering Relationships
  4. Agent Orchestration Architecture
  5. APPLY — Enterprise Procurement Workflow
  6. Worked Example: A Multi-Step Workflow
  7. Engineering Decisions and Trade-offs
  8. Active Industry Practices
  9. ACCOMPLISH — Practical Exercise
  10. Student and Practitioner Project
  11. Check Your Understanding
  12. Active Connections
  13. References and Further Reading

1. Why Agent Orchestration Matters

Consider an enterprise procurement manager asking:

"Check purchase order PO-1048. Verify whether the required material is available elsewhere. If delivery is delayed, recommend a recovery action and prepare the necessary follow-up."

This is not a single question. It is a sequence of dependent tasks.

The AI application may need to retrieve purchase-order information, inspect inventory, compare delivery alternatives, apply procurement policies, prepare a recommendation, and obtain approval before making changes.

Each step depends on information or decisions from previous steps.

What happens if the inventory service is unavailable? What if the purchase-order record is inconsistent? What if a human reviewer rejects the proposed action?

These are orchestration problems.

Agent orchestration is not simply connecting several AI calls. It is engineering the control flow that turns multiple operations into a dependable business outcome.

2. UNDERSTAND — The Concept

What is agent orchestration?

Agent orchestration is the coordination of AI models, tools, workflow steps, decisions, application state, and control mechanisms to accomplish a task.

The orchestrator may be implemented through conventional software logic, a workflow engine, an agent framework, or a combination of these.

Five essential responsibilities

ResponsibilityEngineering Question
PlanningWhich steps are required?
CoordinationWhat should run next, and what depends on what?
State managementWhat has already happened?
ControlWhich operations are permitted?
RecoveryWhat happens when a step fails?

Workflow versus agent

A workflow generally follows a predefined control structure. An agent may dynamically select actions and tools based on intermediate observations.

In practice, production systems often combine both approaches.

For example, an agent may analyze a supplier delay while a deterministic workflow controls approvals, record updates, and completion status.

Common orchestration patterns

  • Sequential: Execute dependent steps in order.
  • Parallel: Run independent operations concurrently.
  • Conditional routing: Choose a branch based on validated results.
  • Iterative: Repeat a bounded process until a condition is satisfied.
  • Supervisor-worker: Delegate specialized tasks to different components.
  • Human-in-the-loop: Pause for an authorized decision.
  • Event-driven: Resume when an external event occurs.

Not every problem needs multiple agents. A deterministic workflow with one model and a few tools may be simpler, cheaper, and easier to test.

3. CONNECT — AI Engineering Relationships

ConceptRelationship to Orchestration
Context EngineeringSupplies relevant information to each step
Token EconomicsControls the cost of repeated model calls
Retrieval EngineeringProvides external evidence
Context ManagementPreserves state and continuity
Structured OutputsDefines data contracts between steps
Tool CallingInvokes external capabilities
MCPProvides standardized access to external capabilities
EvaluationTests both individual steps and overall outcomes
ObservabilityTraces execution, latency, cost, and failures
GovernanceEstablishes accountability and approval controls

Active connection: Orchestration brings together the capabilities studied in earlier lessons into an operational AI application.

4. Agent Orchestration Architecture

User Request

↓

Workflow Controller / Orchestrator

↓

Task Planning and State Initialization

↓

Model and Tool Execution

↓

Result Validation

↓

Decision: Continue, Retry, Escalate, or Stop?

↓

Human Approval When Required

↓

Authorized Business Action

↓

Outcome Verification and Audit Record

State transitions

A workflow should have explicit states, such as:

CREATED
   |
   v
RUNNING
   |
   +--> WAITING_FOR_APPROVAL
   |           |
   |           v
   |        RUNNING
   |
   +--> FAILED
   |
   +--> COMPLETED

Real implementations may need additional states such as cancelled, timed out, rejected, or requiring manual intervention.

Why state matters

State enables a workflow to resume after interruptions, avoid repeating completed actions, and distinguish a pending operation from a successful one.

State should be stored in a durable application system when the workflow must survive process restarts or extended human approval delays.

5. APPLY — Enterprise Procurement Workflow

Scenario: Recovering from a Supplier Delay

A manufacturing company uses an AI assistant to investigate delayed material deliveries.

The assistant has access to fictional procurement, inventory, and supplier systems.

Step 1 — Retrieve purchase order

The system obtains the current order status through an authorized lookup tool.

Step 2 — Check inventory

The application retrieves stock availability from alternative locations.

Step 3 — Evaluate alternatives

The AI analyzes available evidence and prepares possible recovery options.

Step 4 — Apply business constraints

Deterministic checks verify inventory eligibility, policy requirements, and permitted actions.

Step 5 — Request approval

If a transfer or supplier change requires approval, the workflow pauses for the designated decision-maker.

Step 6 — Execute authorized action

The application invokes the approved operation and verifies its result.

Step 7 — Complete and record

The workflow reports the outcome and records the relevant execution history.

Important: The assistant should never describe an operation as completed merely because the model proposed it.

6. Worked Example: A Multi-Step Workflow

The following is a fictional design illustration, not a live enterprise integration.

Sample workflow state

{
  "workflow_id": "WF-1048",
  "po_id": "PO-1048",
  "status": "waiting_for_approval",
  "order_status": "delayed",
  "alternative_stock_available": true,
  "recommended_action": "internal_transfer",
  "approval_status": "pending",
  "execution_status": "not_started"
}

Illustrative orchestration pseudocode

async def process_order(po_id, user):
    order = await get_order(po_id, user)
    validate_order(order)

    if order["status"] != "delayed":
        return {"status": "completed",
                "action": "none"}

    inventory = await check_inventory(order, user)
    validate_inventory(inventory)

    proposal = await recommend_action(
        order, inventory
    )
    validate_proposal(proposal)

    approval_id = await request_approval(
        proposal, user
    )

    # Persist state and stop execution.
    # Resume only after a verified approval event.
    return {
        "status": "waiting_for_approval",
        "approval_id": approval_id,
        "execution_status": "not_started"
    }

This pseudocode illustrates a workflow boundary. A production implementation must authenticate the approver, persist state, resume through a controlled event, enforce authorization, and verify any eventual write operation.

What makes the workflow reliable?

  • Each step has defined inputs and outputs.
  • External results are validated.
  • State is recorded before suspension.
  • Approvals are explicit.
  • Retries are bounded and controlled.
  • Side-effecting actions use duplicate-prevention safeguards.
  • Completion is based on verified execution results.

7. Engineering Decisions and Trade-offs

DecisionBenefitTrade-off
Fixed workflowPredictability and testabilityLess flexibility
Dynamic agent planningAdapts to varied tasksHarder to constrain and evaluate
Parallel executionReduced latencyDependency and concurrency risks
Persistent stateResumabilityStorage and consistency complexity
Automatic retriesFailure recoveryCost and duplicate-action risks
Human approvalStronger oversightAdditional time
Multiple specialized agentsDivision of responsibilitiesCoordination overhead

Common failure modes

  • Infinite or excessive execution loops
  • Incorrect tool selection
  • Loss of workflow state
  • Contradictory intermediate results
  • Repeated actions after retries
  • Unauthorized execution
  • Unbounded token consumption
  • Incorrect completion reporting
  • Prompt injection through retrieved data or tool results

Recommended engineering controls

  • Maximum step and execution budgets
  • Timeouts and bounded retries
  • Checkpointing and durable state
  • Idempotency for operations with side effects
  • Structured contracts between components
  • Explicit approval boundaries
  • Least-privilege tool permissions
  • Execution tracing and audit records
  • Outcome-based evaluations
Reliable orchestration requires a controlled workflow, not merely a capable model.

8. Active Industry Practices

Established engineering approaches

  • State-machine and graph-based workflows
  • Task dependency management
  • Tool execution with validation
  • Human approval checkpoints
  • Persistent workflow state
  • Execution tracing and monitoring

Evolving AI engineering practices

  • Model-directed workflow routing
  • Supervisor and specialist-agent architectures
  • Agent evaluation using execution traces
  • Policy-aware tool orchestration
  • Adaptive planning with bounded autonomy
  • Durable execution for long-running agents

Relevant technologies

Developers may evaluate frameworks such as LangGraph, Microsoft Agent Framework, OpenAI Agents SDK, and conventional workflow engines.

These technologies have different architectures and operational characteristics. Framework selection should follow the requirements of the application rather than determine the architecture in advance.

Industry applications

Agent orchestration is relevant to customer support, software engineering, incident response, research assistants, enterprise operations, procurement, document processing, and multi-step business automation.

Practice status: Established workflow-engineering principles combined with evolving agentic AI architectures.

Reviewed: November 2026.

9. ACCOMPLISH — Practical Exercise

Exercise: Design a Procurement Recovery Workflow

Use this fictional scenario:

Purchase order: PO-2056

Status: Delayed

Required quantity: 500 units

Alternative location stock: 350 units

Proposed action: Partial internal transfer

Approval: Required

Your tasks

  1. Define the workflow objective.
  2. List the required tools and data sources.
  3. Identify sequential and parallel steps.
  4. Define workflow states and transitions.
  5. Specify validation checkpoints.
  6. Identify actions requiring approval.
  7. Design failure and retry handling.
  8. Define completion and escalation conditions.
  9. Explain how the remaining 150-unit shortage will be handled.

Reusable AI-assisted prompt

Act as an enterprise AI workflow architect.

Design an agent orchestration workflow
for a delayed purchase order.

Scenario:
- Order: PO-2056
- Required quantity: 500 units
- Alternative stock: 350 units
- Supplier delivery: delayed
- Internal transfer: approval required

Provide:
1. Workflow objective.
2. Required tools and data.
3. Step-by-step execution plan.
4. State transitions.
5. Validation rules.
6. Approval checkpoints.
7. Failure recovery strategy.
8. Cost and execution limits.
9. Observability requirements.
10. Completion and escalation criteria.

Distinguish AI-generated recommendations
from verified system actions.

Do not claim any real action was executed.

Accomplishment: Produce an orchestration design that can be reviewed for reliability, authorization, recovery, and measurable completion.

10. Student and Practitioner Project

Mini Project: Build a Stateful Procurement Agent

Objective: Prototype a multi-step AI workflow using simulated enterprise systems.

Project requirements

  1. Create fictional purchase-order and inventory datasets.
  2. Define lookup and simulated action tools.
  3. Implement a workflow controller.
  4. Persist workflow state between steps.
  5. Use structured inputs and outputs.
  6. Introduce an approval checkpoint.
  7. Simulate a tool timeout and a service failure.
  8. Test workflow resumption after interruption.
  9. Prevent duplicate side effects.
  10. Record execution traces and evaluate outcomes.

Suggested evaluation metrics

MetricWhat It Measures
Task completion rateSuccessful completion of authorized workflows
Step accuracyCorrect execution of required stages
Recovery successResumption after failures
State consistencyCorrectness of persisted workflow information
Approval complianceWhether required approvals are enforced
Duplicate action rateRepeated side effects after retries
Execution costModel and tool resource consumption
End-to-end latencyTotal workflow processing time

Project deliverable: A workflow diagram, working prototype or design, sample execution traces, evaluation results, and an engineering recommendation.

11. Check Your Understanding

  1. What is agent orchestration?
  2. How is orchestration different from tool calling?
  3. What is the difference between a fixed workflow and a dynamic agent?
  4. Why is persistent state important?
  5. When should workflow steps run in parallel?
  6. How should approval checkpoints be implemented?
  7. Why are retries dangerous for write operations?
  8. How would you measure end-to-end workflow reliability?

Reflection: If every individual AI step succeeds but the overall workflow performs an unauthorized action, has the system succeeded? What does this reveal about orchestration quality?

12. Active Connections

Coming next — #011: Agent Evaluation: Measuring Whether AI Workflows Actually Succeed.

13. References and Further Reading

  1. LangGraph — Overview
  2. OpenAI Agents SDK — Documentation
  3. Microsoft Agent Framework — Documentation
  4. Temporal — Durable Execution Documentation
  5. Model Context Protocol — Official Documentation

Framework capabilities and implementation guidance evolve. Verify the current documentation when building production systems.


Final Takeaway

A reliable AI workflow is not defined by how many agents or tools it uses. It is defined by whether it coordinates work correctly, handles failures, respects controls, and delivers a verified outcome.

AI Engineering — Active Concepts & Practices
Active Concept #010 — Agent Orchestration

AIYING — Accomplishing with AI

Understand → Connect → Apply → Accomplish

Tuesday, November 10, 2026

The Effective AI Engineer #023: The Engineer Who Checked Before Resuming

THE EFFECTIVE AI ENGINEER

A Case-Based Approach

CASE #023

The Engineer Who Checked Before Resuming

Choose Work That Matters

By Ravindra Dastikop
AIYING — Accomplishing with AI



The agent had saved its progress. Had the organisation preserved its permission to continue?

1. The current engineering challenge

AI agents increasingly perform work in the background while a user continues the conversation, changes requirements or starts another task.

LangChain’s Agents Are Going Async, published on 5 November 2026, describes an architecture in which a user-facing orchestrator stays available while background subagents work independently. It also discusses task updates, cancellation and approval handling. The article identifies task notifications as beta functionality. [1]

That architecture creates a practical design question:

When a background agent resumes, how does it establish that its next action still matches the user’s current intent?

This case focuses on changing instructions and the validity of an approved action. Reliable execution must account for what happened while the worker was waiting.

↑ Back to contents

2. Audience and learning outcomes

  • Freshers and students: distinguish saved progress from permission to act.
  • AI builders and developers: design background tasks that tolerate changing instructions.
  • AI and harness engineers: implement task versions, approval boundaries and cancellation states.
  • Freelancers and consultants: define what a client has authorised an assistant to do.
  • Managers and faculty: examine accountability when approval and execution occur at different times.

Prerequisites: basic familiarity with agents, APIs, workflow state and human approval.

After studying the case, learners should be able to:

  1. Identify how background work becomes stale.
  2. Bind approval to a specific proposed action.
  3. Distinguish cancellation requested from cancellation confirmed.
  4. Design a check immediately before an external action.
  5. Explain when work can be reused and when approval must be renewed.

↑ Back to contents

3. The story: an approval overtaken by events

CedarWorks Services coordinated equipment maintenance across several offices. Its operations team spent substantial time finding technicians, checking access windows and preparing appointment confirmations.

Meera, an AI engineer, built an assistant that could read a maintenance request, research providers, compare appointments, prepare a booking and ask a supervisor for approval. Following approval, it could submit the booking through a vendor API.

Initially, the assistant handled one request at a time. A slow provider search left the supervisor waiting.

The team introduced background workers. The supervisor could now continue working while the assistant searched for appointments.

During demonstrations, the improvement was obvious. The assistant stayed responsive. Several searches could progress independently.

Then Meera tested what happened when a request changed while a worker was waiting.

“Arrange maintenance for the cooling unit at the North office on Friday morning. Prepare the booking for approval.”

The assistant created request version 1. A worker found a technician and prepared a booking. The supervisor approved it, but submission remained queued.

Before submission began, the facilities manager reported that the North office would be inaccessible on Friday.

The supervisor told the assistant:

“Change it to the South office on Monday afternoon. Keep the same maintenance scope.”

The conversational assistant acknowledged the change. However, the queued worker still held the earlier approved action.

When it resumed, it was ready to book the North office for Friday.

Its stored information appeared consistent: a request existed, a provider had been selected, approval had been recorded and submission remained incomplete.

But those records described an instruction the user had replaced.

↑ Back to contents

4. Exhibit A: one task, two versions

Illustrative teaching timeline; these are fictional events.

Time Event Implication
09:00 North office, Friday morning requested. Version 1 created.
09:06 Worker prepares booking. Proposal belongs to version 1.
09:08 Supervisor approves proposal. Approval covers that proposal.
09:09 Submission waits in queue. External booking has not occurred.
09:11 User changes location and appointment window. Version 2 supersedes version 1.
09:12 Assistant acknowledges update. Conversation reflects version 2.
09:14 Original worker resumes. Pending action still reflects version 1.

The defect was a disagreement between the current request and the pending action.

↑ Back to contents

5. The decision point

The product manager argued:

“The supervisor already approved the maintenance. We should avoid asking again.”

The operations lead disagreed:

“I approved a specific visit. The location and time were part of that decision.”

Meera considered three options.

Option Benefit Limitation
Resume the previously approved booking. Fast; uses existing approval. Acts on superseded instructions.
Replace booking details and reuse approval. Avoids another approval request. Changes what the supervisor reviewed.
Retain useful research, invalidate the old action and review the revised proposal. Preserves useful work and respects the change. Requires explicit version and approval handling.

Stopping every worker whenever any message arrived was another possibility. However, an unrelated question should not necessarily invalidate maintenance work.

Pause and decide

What should happen to the queued booking, the earlier approval and the provider research? Define your answer before reading the worked analysis.

↑ Back to contents

6. What published sources establish

LangGraph’s interrupt documentation explains that an interrupt saves graph state and waits for input. Its documentation also explains that resuming an interrupted node restarts that node from its beginning, making the treatment of side effects important. Code executed before the interrupt must be safe to repeat. [2]

Persistence and checkpoints support retaining execution state and recovering workflow progress. [3]

The application-level inference: the system must additionally establish whether the proposed action remains valid under current instructions. A persisted approval record alone cannot answer that business question.

The sources support the technical context. The fictional incident and the following control design are teaching constructions.

↑ Back to contents

7. The thinking shift

Hidden assumption: if a task can resume from saved state, its earlier permission remains sufficient.

PO — a deliberate provocation: “The agent may remember everything and still have no permission to continue.”

This statement is used to generate possibilities. It is not a claim that every resumed task needs a new human approval.

Movement: separate the information needed to continue working from the authority needed to perform an external action.

  • Research can remain useful after a request changes.
  • A proposal can become obsolete while its supporting research remains useful.
  • Approval can cover a specific action or an explicitly defined range of actions.
  • A worker can finish successfully while producing an unusable result.

Discovery: resumption should include a decision about applicability, rather than relying only on the presence of saved state.

This is the author’s lateral-thinking application to the engineering problem.

↑ Back to contents

8. Worked analysis

Meera chose to retain useful research while invalidating the old proposal and approval. She separated three concepts:

  1. Research: information collected while preparing an action.
  2. Proposal: the exact action presented for review.
  3. Authority: permission to execute that proposal under stated conditions.

Changing the office and appointment window invalidated the booking proposal. In this application, the approval covered those details, so it also became unusable.

Some provider research could remain useful. A provider’s service coverage might still apply, while its Friday availability would require another check.

The system marked the first proposal as superseded, prevented it from reaching submission and prepared a replacement.

The supervisor could then receive this message:

“The earlier booking has not been submitted. Your change replaces the approved location and appointment window. I am preparing a revised proposal for review.”

That wording is appropriate only after the system has established that submission has not occurred.

↑ Back to contents

9. A proposed approval contract

For CedarWorks, an approval should identify what the person reviewed and the conditions under which it may be used.

Field Purpose
Task IDIdentifies the maintenance workflow.
Request versionIdentifies the applicable instruction.
Proposal ID and versionIdentifies the reviewed action.
Action details or digestBinds approval to particular booking content.
Approver identity and authorityEstablishes who approved and whether they could approve.
Approval time and validity conditionsDefines when approval may be used.
Approval statusRecords approved, revoked, expired, superseded or consumed.

A digest can bind a record to particular content. It does not establish that the content is correct or authorised.

CedarWorks required renewed approval for changes to location, appointment window, provider or maintenance scope. Another application might permit a bounded range of choices, provided those boundaries were explicit when the person approved.

↑ Back to contents

10. Check at the action boundary

Immediately before booking, the execution service should establish that:

  1. The task remains active.
  2. The proposal belongs to the current applicable request version.
  3. The approval covers that proposal.
  4. The approval remains valid.
  5. Relevant availability and access conditions remain acceptable.
  6. The booking has not already been submitted.

The check and the transition into submission must be coordinated. Otherwise, an update could arrive after validation but before the external call.

One implementation could use a conditional database transition that permits submission only while the expected task version remains current.

A prompt asking the model to “check the latest instructions” can support reasoning, but consequential execution should also enforce the relevant conditions in application logic.

↑ Back to contents

11. Cancellation and uncertain outcomes

Meera distinguished four user-visible states:

  • Cancellation requested: the system has received the instruction.
  • Cancellation confirmed: the pending action has been prevented.
  • Action already submitted: an external amendment or cancellation may be necessary.
  • Outcome unknown: the system must reconcile the provider’s state.

If the booking already existed, the assistant should report that fact and follow the appropriate amendment process.

Stopping a worker does not, by itself, establish that an external appointment has been cancelled.

The interface should communicate the strongest conclusion supported by evidence.

↑ Back to contents

12. Practical verification plan

Proposed tests. No implementation was executed for this case.

Scenario Expected behaviour
Approval followed by no relevant change.Submit the approved proposal if other conditions remain valid.
Location changes before submission.Block the old proposal and prepare a replacement.
User sends an unrelated question.Retain valid maintenance approval.
Old worker returns after a newer worker.Retain the trace and prevent stale action.
Approval callback arrives twice.Avoid duplicate submission.
Worker restarts around an interrupt.Avoid repeating external effects.
Cancellation arrives before submission.Prevent action and confirm the outcome.
Cancellation arrives after submission.Report booking state and amendment options.
Provider availability changes.Recheck the proposal and approval rules.
Vendor response is lost.Reconcile the outcome before another attempt.

Useful measures include stale actions blocked, duplicate submissions, approval-to-action mismatches and time spent resolving uncertain outcomes.

Measure correctness alongside responsiveness.

↑ Back to contents

13. Learner assignment and project

Prepare a design note answering:

  1. At what event does version 1 become superseded?
  2. Which research can version 2 reuse, and why?
  3. Which changes require a new approval?
  4. How will two workers be prevented from submitting competing proposals?
  5. What happens when cancellation races with submission?
  6. What evidence explains the final action to the supervisor?

Submit:

  • A task state table.
  • An example approval record.
  • Five failure scenarios and expected outcomes.
  • A short explanation suitable for a nontechnical client.

Student project: build the smallest useful simulation

Create a simple workflow with a request, proposal, approval and simulated booking. It can use a spreadsheet, a no-code tool or a small program. Add a way to change the request while the booking waits.

Demonstrate that the old proposal cannot execute after a relevant change. Use a simulated vendor service rather than real appointments. Record the event sequence and explain the outcome.

Advanced extension: allow a supervisor to approve any appointment within a stated date range and cost limit. Explain how execution verifies those boundaries and when further approval is required.

↑ Back to contents

14. Reusable engineering prompts

Prompt 1 — Find stale-work risks

Review this background workflow. Identify every point where a changed instruction could make a worker’s output or pending action obsolete. Separate reusable research from proposed actions. State the evidence needed to decide what remains valid.

Prompt 2 — Define approval scope

Define the exact action a person approves, permitted variations, expiry conditions and changes that invalidate approval. Identify ambiguous wording. Propose the application checks needed before execution.

Prompt 3 — Test competing events

Generate event sequences involving approval, user updates, worker completion, cancellation, restart and external submission. State the expected outcome for each sequence. Include cases where the external outcome is unknown.

Prompt 4 — Review user messages

Check whether these status messages distinguish requested, pending, confirmed, failed and unknown outcomes. Flag any statement stronger than the available evidence. Rewrite it accurately and clearly.

↑ Back to contents

15. Teaching and team discussion guide

Suggested session: 75 minutes.

  • 10 minutes: read the story and make an individual decision.
  • 15 minutes: compare the alternatives.
  • 20 minutes: design the approval and state records.
  • 20 minutes: challenge designs with competing event sequences.
  • 10 minutes: explain the chosen behaviour to the supervisor.

Assess designs on clarity of authority, treatment of changed instructions, handling of uncertain outcomes and preservation of useful work.

For freshers, focus on the timeline and user messages. For experienced engineers, examine concurrency and the boundary between local state and external effects. For managers, discuss acceptable approval scope and responsibility for exceptions.

Discussion question:

Which decisions can the organisation authorise in advance, and which changes should return control to a person?

↑ Back to contents

16. Sources and research limits

Sources checked: 10 November 2026.

  1. LangChain — Agents Are Going Async. Sydney Runkle and Thushanth Bengre, 5 November 2026. Primary source for the recent asynchronous subagent architecture, task management and the stated beta limitation for task notifications.
    Read the original article
  2. LangGraph documentation — Interrupts. Primary documentation for interrupt handling, resumption and considerations around side effects.
    Read the documentation
  3. LangGraph documentation — Persistence. Supporting documentation for workflow state, checkpoints and recovery.
    Read the documentation

Research limits: these sources establish the technical context. They do not document the CedarWorks scenario, validate the proposed control design or establish measured business outcomes. No performance improvement, incident reduction or production readiness is claimed.

Before implementation, verify the installed framework version, relevant API behaviour, persistence configuration and the external provider’s submission, cancellation and reconciliation capabilities.

↑ Back to contents

17. The enduring lesson

Saved progress tells an agent where it can continue. Current intent and valid approval determine whether it should.

Keep the work moving. Check the authority before acting.

Choose Work That Matters

Ravindra Dastikop
AIYING — Accomplishing with AI

For students, professionals, freelancers, faculty and teams using cases for learning, teaching and training.

Explore the AIYING blog

The Effective AI Engineer — A Case-Based Approach | Case #023

Friday, October 30, 2026

AI Innovation Project #003 — Build an AI Perspective Council with ChatGPT, Python and LangGraph

Build an AI Perspective Council with ChatGPT, Python and LangGraph



PO Prompts #003 | Think the Unthinkable

Project Description

What if every employee had 100 AI assistants—but none of them was allowed to do the employee's work?

This deliberate provocation challenges the conventional assumption that the primary purpose of AI assistants is to automate tasks.

Instead, imagine AI assistants acting as independent thinking partners, examining a problem from different perspectives, challenging assumptions, identifying overlooked risks and discovering unexpected opportunities.

The proposed innovation: An AI Perspective Council—a multi-perspective decision-support system that helps people make better-informed decisions without surrendering human judgment.

The project begins with five AI perspectives and can later expand to a larger, dynamically selected council.

1. Project Objective

Design, develop and evaluate an AI-powered decision-support application in which multiple specialized AI perspectives examine the same problem, exchange critiques and produce a consolidated briefing for a human decision-maker.

The system should:

  • Challenge conventional assumptions.

  • Explore alternative interpretations of problems.

  • Identify opportunities and potential consequences.

  • Surface disagreements and missing evidence.

  • Generate unconventional but actionable options.

  • Support transparent, accountable human decisions.

Expected outcome: A working AI Perspective Council prototype that can be tested against conventional single-assistant AI decision support.

2. Lateral Thinking Foundation

Conventional Thinking

One employee encounters a problem, asks an AI assistant for recommendations and receives an answer.

Adding more assistants might simply mean automating more tasks.

PO Provocation — Exaggeration

PO, every employee has 100 AI assistants, but none can perform the employee's tasks.

This is a deliberate thinking provocation, not a literal implementation requirement.

MOVE — Extract a Principle

If assistants cannot execute tasks, what useful roles remain?

They could challenge assumptions, examine consequences, uncover alternatives, question evidence and reveal opportunities.

The underlying principle is that AI assistance can increase the diversity of thinking rather than merely the volume of work completed.

New Direction

Create an AI council in which specialized perspectives examine a problem independently and then challenge one another.

The goal is not to manufacture artificial agreement.

It is to expose important differences in reasoning and help humans discover options they might otherwise overlook.

GENERATE

Use generative AI to develop multiple perspectives, explore emerging alternatives and refine unconventional ideas.

JUDGE

Assess novelty, relevance, feasibility, evidence quality, cost, disagreement and risks.

ACCOMPLISH

Build and evaluate a five-perspective AI Council MVP.

Distinction: The exaggeration and movement techniques are inspired by Edward de Bono's lateral-thinking methods. The AI Perspective Council is a proposed contemporary application, not a technique attributed to de Bono.

3. Recommended Technology Stack

ComponentRecommended ToolPurpose
AI modelsOpenAI GPT modelsGenerate and critique alternative perspectives
No-code prototypeChatGPT Custom GPTTest council-style prompting
Programming languagePythonImplement application logic
AI integrationOpenAI APIInvoke specialized AI perspectives
Workflow orchestrationLangGraphCoordinate independent analysis, critique and synthesis
User interfaceStreamlitBuild an interactive decision-support dashboard
Structured outputsPydanticValidate perspective responses and decision briefs
Data storageSQLiteStore scenarios, analyses and evaluation results
Data analysispandasCompare outcomes across experiments
VisualizationPlotlyDisplay scores, disagreements and evaluation results
TestingpytestTest workflow behavior and output validation
DeploymentStreamlit Community CloudHost a non-sensitive demonstration

Recommended Development Strategy

Stage A — No-code: Simulate five perspectives using a Custom GPT or structured ChatGPT prompt.

Stage B — Low-code: Build a Streamlit interface connected to the OpenAI API.

Stage C — Orchestrated application: Introduce LangGraph for independent analysis, controlled critique, synthesis and review.

A multi-agent framework is optional for the first prototype. Multiple perspectives can initially be implemented using separate model calls with distinct instructions.

4. Proposed System Architecture

Human Decision Problem → Context Validation → Perspective Selection → Independent AI Analysis → Cross-Perspective Critique → Evidence and Risk Review → Decision Brief → Human Judgment

Five Core AI Perspectives

1. The Customer Advocate

Examines customer needs, usability, expectations and possible dissatisfaction.

2. The Critical Challenger

Questions assumptions, identifies weak reasoning and challenges proposed solutions.

3. The Evidence Researcher

Identifies evidence requirements, unsupported claims, uncertainty and information gaps.

4. The Risk Analyst

Examines operational, financial, ethical, regulatory and implementation risks.

5. The Innovation Explorer

Uses deliberate provocations and movement techniques to discover unconventional alternatives.

Council Coordinator

A separate coordinating workflow collects the perspectives, highlights disagreements and prepares a consolidated decision brief.

The coordinator must not silently erase minority views or convert speculation into established evidence.

Human Decision-Maker

The user reviews the council's findings, requests clarification, compares alternatives and makes the final decision.

5. Reusable Prototype Prompt

Create a Custom GPT called AI Perspective Council using the following instructions:

You are an AI Perspective Council designed to improve human decision-making through multiple independent perspectives.

When the user presents a decision problem:

  1. Clarify the decision, objectives, constraints and available evidence.

  2. Simulate five perspectives: Customer Advocate, Critical Challenger, Evidence Researcher, Risk Analyst and Innovation Explorer.

  3. Have each perspective independently examine the problem and identify important considerations.

  4. Require the Innovation Explorer to apply a deliberate lateral-thinking provocation and movement technique.

  5. Identify agreements, disagreements and conflicting assumptions.

  6. Generate at least three distinct decision alternatives, including one non-obvious option.

  7. Evaluate alternatives against user-defined criteria.

  8. Identify missing evidence and suggest practical validation experiments.

  9. Prepare a concise decision brief with recommendations, uncertainties and unresolved disagreements.

  10. Leave the final decision to the human user.

Never fabricate evidence, external research, expert identities or independent verification.

Clearly distinguish facts, assumptions, AI-generated hypotheses and recommendations.

Do not force consensus when meaningful disagreements remain.

Implementation note: A Custom GPT can simulate multiple perspectives, but this does not establish that the analyses are truly independent. The application version should use separate model calls and controlled information sharing to better test perspective diversity.

6. Minimum Viable Product (MVP)

MVP Objective

Build a functional web application where a user enters a workplace decision and receives a structured analysis from five AI perspectives.

Essential Features

Feature 1 — Decision Input

The user enters:

  • Decision question

  • Business context

  • Desired outcome

  • Constraints

  • Evaluation criteria

Feature 2 — Five-Perspective Analysis

The application invokes five separately instructed AI perspectives and displays their findings.

Feature 3 — Assumption Challenger

The system identifies at least three assumptions that may be limiting the decision.

Feature 4 — Lateral Thinking Explorer

The Innovation Explorer applies one explicit provocation method and one movement technique to develop a non-obvious alternative.

Feature 5 — Council Discussion

Perspectives critique selected claims or proposals from other perspectives.

Feature 6 — Decision Comparison

The system compares at least three alternatives using a transparent scoring rubric.

Feature 7 — Decision Brief

The application generates a report containing:

  • Problem definition

  • Important assumptions

  • Five perspective summaries

  • Agreements and disagreements

  • Alternative solutions

  • Evidence gaps

  • Risk considerations

  • Suggested experiments

  • Human decision checklist

Feature 8 — Export

Allow the user to export the briefing as Markdown or PDF.

Example Use Case

Decision: Should a small company replace its customer support team with an AI chatbot?

The five perspectives might respond as follows:

PerspectiveKey Question
Customer AdvocateWhat happens when customers need empathy or escalation?
Critical ChallengerAre we assuming that automation requires replacement?
Evidence ResearcherWhat evidence supports the expected savings and service quality?
Risk AnalystWhat happens when the chatbot gives incorrect or sensitive advice?
Innovation ExplorerWhat if human agents handled only the moments where human judgment matters most?

Possible innovation: Instead of full replacement, design an AI-supported customer service system where routine queries are automated and human staff specialize in complex, emotional or high-consequence interactions.

This is a hypothesis to test, not a predetermined recommendation.

7. Evaluation Experiment

Research Question

Does a multi-perspective AI Council produce better-supported and more innovative decisions than a conventional single AI assistant?

Experimental Design

Prepare 10–20 realistic decision scenarios spanning business, education, technology and workplace operations.

Compare three conditions:

A — Human-only: Participants analyze the problem without AI.

B — Single AI Assistant: Participants receive a conventional AI-generated recommendation.

C — AI Perspective Council: Participants receive the council's structured analysis and disagreements.

Use the same problem information and evaluation criteria across conditions. Where feasible, randomize or counterbalance scenarios and have reviewers assess anonymized decision outputs.

Evaluation Metrics

MetricMeasurement
Decision qualityIndependent reviewer rubric
Perspective diversityNumber of substantively distinct considerations
Assumption discoveryRelevant hidden assumptions identified
Innovation qualityNovelty and usefulness of alternatives
Evidence qualityAccuracy and traceability of claims
Risk coverageRelevant risks identified
Human understandingParticipant comprehension of trade-offs
Decision confidenceSelf-reported confidence and calibration
EfficiencyTime, latency and API cost
UsabilityParticipant feedback

Important Evaluation Safeguards

More perspectives do not automatically mean better decisions.

Multiple AI perspectives can share biases, repeat the same errors or create a misleading appearance of independent agreement.

The experiment should therefore measure meaningful diversity, factual reliability, user workload and costs—not merely the quantity of generated ideas.

A small pilot provides preliminary findings rather than proof of general effectiveness.

8. Suggested Development Roadmap

Phase 1 — Concept Validation

Duration: Approximately 2–3 days

Create a Custom GPT prototype and test five representative decision problems.

Deliverable: Working prompt-based council demonstration.

Phase 2 — MVP Development

Duration: Approximately 1–2 weeks

Build a Python and Streamlit application using the OpenAI API.

Implement independent perspective calls, structured responses, a comparison view and decision brief export.

Deliverable: Functional web prototype.

Phase 3 — Council Orchestration

Duration: Approximately 1 week

Introduce LangGraph if the workflow requires explicit stages, controlled critique and review checkpoints.

Deliverable: Coordinated multi-perspective workflow.

Phase 4 — Quality and Safety Testing

Duration: Approximately 1 week

Test prompt injection resistance, unsupported claims, output consistency, privacy protections, costs and error handling.

Deliverable: Test report and revised prototype.

Phase 5 — Comparative Evaluation

Duration: Approximately 2 weeks

Run decision experiments with representative users and independent reviewers.

Deliverable: Evaluation dataset and comparative analysis.

Phase 6 — Improvement and Expansion

Explore additional perspectives, adaptive perspective selection, verified document retrieval and domain-specific councils.

Deliverable: Enhanced prototype and implementation recommendations.

Durations are illustrative estimates for a small prototype, not guaranteed delivery commitments.

9. Expected Project Deliverables

  1. AI Perspective Council Custom GPT prototype.

  2. Reusable multi-perspective prompting framework.

  3. Python and Streamlit web application.

  4. Five specialized AI perspective modules.

  5. Optional LangGraph orchestration workflow.

  6. Structured decision-analysis templates.

  7. Decision brief export functionality.

  8. Evaluation dataset and scoring rubric.

  9. Comparative pilot report.

  10. Technical documentation and deployment guide.

10. Future Extensions

Once the MVP is evaluated, possible enhancements include:

Dynamic Perspective Selection: Choose the most relevant perspectives for each problem rather than always using the same five.

100-Perspective Library: Maintain a catalog of specialized perspectives, invoking only a useful subset for each decision.

Evidence-Grounded Council: Connect approved documents and verified information sources so perspectives can support claims with traceable evidence.

Human-AI Debate: Allow users to challenge individual perspectives and request counterarguments.

Decision Memory: With appropriate permissions, record decisions, assumptions, outcomes and lessons learned for future review.

Specialized Councils: Develop versions for AI engineering, education, entrepreneurship, product design and organizational governance.

11. What Makes This an AI Creativity Project?

Conventional AI assistance often follows a familiar pattern:

Ask → Generate → Select

The AI Perspective Council explores a different approach:

Disrupt → Move → Discover → Explore with AI → Judge → Accomplish

The project begins by exaggerating the number of AI assistants while removing their ability to execute tasks.

That provocation creates an unexpected question:

What else could AI assistants contribute besides doing work?

Through deliberate movement, we discover the possibility of AI systems designed to expand the diversity of human thinking.

The goal is not to replace human judgment with an artificial committee.

It is to help people recognize assumptions, understand disagreements, discover alternatives and make better-informed decisions.

Lateral thinking is the creative engine. AI is the exploration amplifier. Accomplishment is the destination.


Project status: Proposed innovation concept and technical blueprint. Prototype development and experimental validation remain future work.

PO Prompts — Think the Unthinkable.

AIYING — Accomplishing with AI.

Accomplish with AI

Powered by Blogger.

Featured post

AI Engineering Hands-On Lab #001 — Build an AI Answer Reliability Test Bench Without Code

AIYING | Daily 24 — Post 009 AI Engineering Hands-On Lab #001 Build an AI Answer Reliability Test Bench — Without Writing Code Lea...

Search This Blog

List of blogs

Search This Blog

About

Translate

Instant Stories

Read in Your Language

Test

share this

ShareThis

Popular Posts