Workflows, tools e adapters

Workflows materializam coordenação; tools executam capacidades; adapters conectam contratos do método a runtimes específicos.

Tool contract

Cada tool declara:

name e purpose
input/output schema
side effects
required identity e permissions
data/action scope
idempotency
cost/meter
telemetry
error behavior
owner e version

Tools genéricas de escrita em produção devem ser evitadas quando procedures tipadas podem limitar action scope.

Adapter

Adapter traduz capability canônica para tecnologia específica sem alterar significado do contrato. Exemplos: semantic contract para objeto do runtime, trace para OpenTelemetry, lineage para OpenLineage, tool contract para MCP ou API.

MCP e protocolos

MCP pode padronizar descoberta e invocação de tools, mas não substitui authority, materiality, purpose, budget ou decision policy. O Harness e o policy layer permanecem responsáveis por permitir, restringir ou bloquear.

Determinismo

Cálculos críticos, state transitions, budget enforcement e policy checks devem ser determinísticos quando possível. LLMs podem interpretar contexto e propor ações, mas outputs são validados antes de side effects.

Workflow states

Um workflow deve declarar started, waiting, blocked, completed, failed, cancelled e expired, além de domain states específicos. Retries precisam ser idempotentes ou compensáveis.

Observability

Cada run recebe trace ID e liga project, epic, task, agent, tool, artifact, gate e cost. Telemetry respeita privacy e não replica contexto sensível desnecessário.

Technology neutrality

O Public Method define contracts. Technology Packs implementam OpenAI, Anthropic, Snowflake, Databricks, Fabric, cloud services, local runtimes ou APIs. Nenhum fornecedor define o Core.