Automation architecture: six platform choices

Choose a role before choosing a platform

A specification describes intended behavior. A workflow coordinates steps. A connector exposes an interface. Observability records what happened. These responsibilities can cooperate, but selecting a product for one does not validate the others. Start with a measured gap in your existing process, such as an inability to trace a failed synthetic step. Avoid introducing another scheduler when the actual missing artifact is a task specification.

The six choices below reflect the supplied primary-source review observed on 2026-10-30. They are foundation decisions with explicit limits, not deployment announcements. An authenticated client connection is not verified. No platform was installed, benchmarked, or connected by this editorial lane.

The decision matrix

Explain the tradeoffs

Activepieces is a candidate discovery surface because the supplied documentation review establishes MCP support. Its MIT core excludes enterprise directories, and capabilities such as multi-tenancy, roles, embedding, or audit may require enterprise terms. A card saying “MIT” does not settle the licensing of every feature or deployment mode. Keep discovery separate from executing an action, which may also incur credits or affect an external service.

Spec Kit contributes an authoring method rather than a runtime. Its value here is clearer behavior, planning, and acceptance inside the existing packet workflow. OpenSpec may help with a narrowly scoped change description, but adding it as a second compulsory authority would complicate review. Both are MIT projects in the supplied review. Assertions in the transcript that they provide REST or official MCP interfaces are unsupported.

Phoenix addresses the observation side. The supplied review documents built-in MCP, but that does not grant a client connection or permission to expose trace data. Its ELv2 terms restrict offering substantial functionality as a hosted or managed service. The accepted boundary is an internal pilot with synthetic traces. This is a planning constraint, not a blanket legal conclusion about every deployment; exact version and intended use need review before expansion.

Kestra has an Apache 2 core and documented flows MCP support, with enterprise RBAC separate. Runtime adoption is deferred until an existing scheduler gap is measured. Windmill also has documented MCP, but its source AGPL terms and official Community binary commercial wrapping restrictions differ. Product embedding is deferred. An internal script benchmark could be considered later under a bounded packet after deployment-specific licensing checks.

Draw a minimal proposed architecture

For an offline exercise, draw this sequence: authoritative packet, synthetic input fixture, local step simulator, redacted event record, reviewer worksheet. Label optional discovery as a separate branch that only describes available actions. Label a possible Phoenix trace import as an internal synthetic pilot, not an installed service. Leave Kestra runtime and Windmill embedding outside the implemented boundary. You can produce this diagram without running any platform.

Give every proposed event a run identifier, step identifier, start and finish times, outcome, input fixture revision, and evidence reference. Record timeout, cancellation, and validation failure as distinct outcomes. Keep secrets and personal data out of traces. A trace that says a step started does not prove completion; a successful mock does not prove a real service accepted a request. Separate these statements in the reviewer worksheet.

Exercise: compare a failure and a success

Invent a three-step document preparation process. In one case validation succeeds and a draft is produced; in another a required field is missing and processing stops. Write the expected event sequence for both. Identify the smallest component needed to inspect the difference. For each of the six platforms, state whether it contributes a necessary role now, an optional experiment, or deferred scope. Do not install or activate anything.

Acceptance: the diagram names one task authority, explicitly separates discovery and execution, includes a failure outcome, and keeps license and telemetry questions visible. A reviewer can explain why each deferred product stays deferred. The result is an architecture proposal with testable boundaries, not an orchestration deployment.

Sources and next reading

Read spec-driven packets to define the pilot, data provenance to design its records, and the directory landing guide for readiness terminology. Existing knowledge practice and adoption paths are related native navigation. Current runtime compatibility, feature editions, retention settings, and operational ownership remain unknown until separately checked.