Your task is to take the provided technical description and ...

Prompt

Your task is to take the provided technical description and rewrite it as a single, comprehensive prompt. Write it as if you were about to build the entire system from scratch: describe step by step, from beginning to end, exactly what you will construct and how you will construct it. The wording must be clear, explicit, and complete so that any language model can fully understand and follow the instructions without ambiguity. If the technical description refers to re‑implementing an existing software, do not include or mention the original software’s name in the prompt. Do not add any role‑playing, personalization, or polite filler phrases (e.g., ‘You are a software developer’, ‘As an expert’, ‘Please kindly’). The prompt must remain strictly technical, objective, and instruction‑focused. Absolutely no simplified, mock, placeholder, dummy, simulated, or fake content is allowed. You must require the full software with (all) file(s), in complete, unabridged, production‑ready code. Read it letter by letter, line by line, from beginning to end—you need to understand and remember every little detail! Always read and retain every single character of the provided text content in memory, ensuring no detail is overlooked. A Plan‑Driven Execution Graph is a workflow model in which a system first turns a goal into an explicit plan, then executes that plan through a graph of tasks, dependencies, decision points, and recovery paths. It is especially useful for agentic AI, automation, robotics, data pipelines, and business processes where execution must be traceable, controllable, and able to run independent work in parallel. Core idea Instead of letting an agent repeatedly decide “what should I do next?” from scratch, the system builds a structured execution artifact first: G = (V, E) Where: V is the set of task nodes: planning, retrieval, analysis, approval, tool calls, validation, final response, and so on. E is the set of directed edges that encode task ordering, data dependencies, conditions, retries, or fallback paths. A node becomes runnable when its prerequisites have completed successfully and its preconditions are satisfied. A plan is commonly viewed as a partially ordered collection of steps: it includes preconditions, postconditions, data‑flow relationships, causal links, and ordering constraints. A directed acyclic graph (DAG) is often appropriate because many tasks can proceed concurrently once their dependencies are met. Typical architecture User goal | v Planner | v Plan compiler / validator | v Execution graph | +--> Research A | +--> Research B --> Synthesis --> Validation --> Output | +--> Data lookup | +--> Conditional recovery / replan A practical implementation usually has these components: Component Responsibility Planner Converts an objective into discrete tasks, expected outputs, dependencies, and constraints Graph compiler Converts the plan into typed nodes and edges, checks that dependencies are valid, and rejects cycles when DAG execution is required Scheduler Identifies ready tasks, runs independent tasks in parallel, and respects concurrency, quota, and priority limits Executor Performs individual tasks using tools, APIs, code, databases, human approvals, or specialist agents State store Preserves task inputs, outputs, status, errors, provenance, and execution history Validator Checks completion criteria, schemas, quality thresholds, and policy constraints Replanner Revises only the affected portion of the graph if assumptions fail or new evidence appears Plan‑then‑execute designs deliberately separate strategic planning from tactical task execution. In graph‑based implementations, nodes hold computation and state updates while edges define the control flow, including conditional routing. Why use a graph? A linear plan works for a simple sequence: Collect data → Analyze → Write report But it becomes inefficient or brittle when work branches: Collect sales data Collect support data → Analyze trends → Draft report → Review Collect product data The three collection tasks do not depend on one another, so a graph scheduler can run them at the same time. Graph‑agent approaches use these dependency structures to unlock parallel execution after prerequisites are fulfilled, rather than enforcing a fixed sequential path. Graphs also make decisions explicit: Run data‑quality check | valid? yes → Train model | no v Repair / reacquire data → Run data‑quality check That structure supports observability: you can answer what ran, which inputs it used, why it ran, which condition selected a branch, and where a failure originated. Example: research agent goal: Prepare a sourced market brief nodes: - id: define_scope type: planner output: research_spec - id: collect_market_data type: search depends_on: [define_scope] - id: collect_competitor_data type: search depends_on: [define_scope] - id: collect_regulatory_data type: search depends_on: [define_scope] - id: synthesize type: llm depends_on: - collect_market_data - collect_competitor_data - collect_regulatory_data - id: verify_claims type: validation depends_on: [synthesize] - id: revise_or_publish type: conditional depends_on: [verify_claims] condition: verification_passed The three collection nodes can run in parallel. The synthesis node cannot begin until all required inputs are available. If validation fails, the graph can route to a targeted re‑research or revision node rather than restarting the entire job. Design principles Use typed inputs and outputs. Each node should declare the data it consumes and produces. This prevents vague handoffs between agents or tools. Make dependencies minimal. Do not connect every task to every other task; represent only genuine data or control dependencies. This exposes safe parallelism. Attach success criteria to nodes. Define what completion means: a valid JSON object, a cited answer, a database write confirmation, a test pass, or human approval. Separate planning from action. Planning may be probabilistic or LLM‑driven; execution of validated steps should be as deterministic and auditable as possible. Build explicit failure routes. Include retry policies, alternate tools, escalation, compensation actions, and replan conditions. Persist state. Long‑running workflows need durable task status, idempotency keys, outputs, logs, and provenance. Prevent unsafe automatic actions. Put approval gates ahead of consequential external actions such as sending messages, publishing content, changing records, or making purchases. When it fits Use a plan‑driven execution graph when the work is multi‑step, repeatable, dependency‑heavy, long‑running, or benefits from parallel work. It is particularly valuable when you need predictable cost, audit trails, retries, partial reruns, and clear governance. A simpler reactive loop can be better for short, highly exploratory tasks where the correct next action is impossible to specify until each observation arrives. The strongest systems are often hybrid: build an initial graph, execute it deterministically where possible, and invoke a replanner only when a node fails, new evidence changes assumptions, or a branch condition demands it.