Proposed specificationSource-located exemplarH1

Tool-workflow boundary

Distinguish an operation from an orchestration.

JOIN POINToperation_versus_orchestrationRECORD STATUSCandidate · v0.1.0

UML class view

The proposed contract drawn as participant roles, received calls, and numbered dependencies.

Object interactions

The same roles and calls as a class collaboration and a numbered message sequence.

Object interaction diagram for Tool-workflow boundary, showing role collaboration and a numbered message sequence — FIG. P11 / OBJECT INTERACTIONS
Open full SVG Download PDF

Pointcut

Where the mechanism applies. All four dimensions belong to the proposed match, not just its vocabulary.

Context: The harness exposes both primitive effects and multi-step procedures.
Trigger: The agent chooses a tool or workflow entry point.
Structure: Separate effect/result contracts and workflow ownership of sequencing.
Effect: Workflow orchestration is not mistaken for a single external side effect.

Protected contract

The obligation that clients, operators, and auditors should be able to rely on.

Requires: Tool and workflow descriptors have distinct schemas and execution paths.
Ensures: Retry, budget, and result accounting bind to the correct unit.
Invariant: A workflow cannot hide duplicate irreversible tool effects.
Violation: Nested failures and retries produce explicit ownership and cost records.

Negative control

A single function that happens to call another function is not enough.

Variation & lifecycle

The hot spot is admitted only where the protected semantics survive.

Permitted variation

Workflow DSL, composite tool, procedure service, and sub-agent workflow.

Test obligation

Test retry inside workflow, duplicate steps, and result aggregation.

Evolution question

Did workflow abstractions emerge to contain orchestration complexity?

Prompt + code design

An illustrative prompt and a small design sketch for the proposed contract. Names and APIs are invented; this is not a repository excerpt.

PROMPT SKETCH

Distinguish a primitive tool call from a multi-step workflow. Give each a separate descriptor and execution path, and bind retry, budget, and result accounting to the correct unit.

CODE DESIGN / PYTHON

@dataclass(frozen=True)
class ToolCall:
    name: str
    arguments: dict

@dataclass(frozen=True)
class WorkflowRun:
    name: str
    steps: list[ToolCall]

def execute(unit, runtime):
    if isinstance(unit, WorkflowRun):
        return runtime.run_workflow(unit)
    return runtime.invoke_tool(unit)

Illustrative design sketch. One boundary with two units; shared accounting must not blur which unit failed. This example is a teaching aid, not implementation evidence or a conformance claim.

Detection & matching

The frozen rule that retrieves this record, the canonical source exemplar, and the control that should stay unmatched.

Join point: operation_versus_orchestration
Source locator: Barbaste et al., §14.1, p. 59 (Signal 3, “The disappearing boundary between tool and workflow”); our reframing as a boundary to declare
Lexical cue: (?i)\b(?:tool[_-]?workflow|workflow[_-]?tool|workflow)\b.*\b(?:tool|agent)\b|\b(?:tool|agent)\b.*\bworkflow\bFrozen expression, v0.1.0. A match is a retrieval cue, not a confirmed implementation.
Aliases: None
Canonical exemplar: OpenHands/software-agent-sdkopenhands-tools/openhands/tools/workflow/definition.py:1Support: tests/tools/workflow/test_workflow_tool.py:1
Negative control: A single function that happens to call another function is not enough.

Scope-anchored review. pohe-agent analyze <repo> --pattern P11 anchors the cue to its enclosing declaration and checks a separate operational signature for all four pointcut dimensions. Missing roles and negative-control risks remain visible; a structural match is not E2/E3. Calibration report ↗

Repository files

Up to five public files retrieved by the frozen cue and pinned to the audited commit. A match is a place to inspect, not a confirmed implementation.

01OpenHands/software-agent-sdkopenhands-tools/openhands/tools/workflow/definition.py:1CANONICAL SOURCE 02agno-agi/agnolibs/agno/agno/company/declarations.py:40RETRIEVAL CUE 03bytedance/deer-flowbackend/packages/harness/deerflow/subagents/builtins/bash_agent.py:15RETRIEVAL CUE 04crewAIInc/crewAIlib/crewai/src/crewai/agents/agent_adapters/langgraph/langgraph_adapter.py:171RETRIEVAL CUE 05Darwin-Agent/HarnessXextensions/plugins/workflow/_core/extractor.py:64RETRIEVAL CUE

Evidence & provenance

Each layer answers a different question. Do not substitute retrieval for review.

Source-located exemplar

A concrete source anchor is available for this proposed record. It is one exemplar, not evidence that all repositories—or every contract field—conform.

Review boundary: this candidate and its specification come from an AI-assisted study. Independent human validation remains open.

ANY-EVIDENCE FAMILY COVERAGE30/36

83.3% of repository families in the frozen panel have at least one current cue, historical cue, or canonical source layer. This is not confirmed prevalence.

Current lexical-cue repositories: 33 / 41

Canonical source anchorOpenHands/software-agent-sdk 5c524ad65d81openhands-tools/openhands/tools/workflow/definition.py:1

Supporting surfacetests/tools/workflow/test_workflow_tool.py:1

Workflow definition distinct from tool invocation.

Exploratory retrieval cue Regex / v0.1.0

This expression is a discovery instrument only. A match is a retrieval cue—not a confirmed implementation, pointcut match, or contract proof.