Your workflow is a contract.
Author it. Validate it. Run it.
Stargate components pair a schema contract with a handler — ports derive from the schema, workflows are directed graphs of component references, and engines validate every node boundary of the portable WorkflowSpec before and after each handler runs.
export const conditional = createFlowControl({
name: "flow.conditional",
parameters: {
condition: createParameter({
schema: z.string().min(1), // CEL
}),
},
input: z.object({ data: z.unknown() }),
output: z.object({
true: z.unknown(), // ← port
false: z.unknown(), // ← port
}),
handler: (ctx) => routeBranch(ctx),
});flow.conditional
flow-control · routes on a CEL expression
data
input port
true
output port
false
output port
Most workflow tools optimize for how fast you can wire nodes together. Stargate optimizes for the correctness and portability of the artifact itself— a validated graph that isn't welded to the runtime that drew it.
A workflow you can trust before it runs.
Components define language-aware schema contracts in a registry, workflows are directed graphs of references to them, and engines execute the portable spec — validating at every step.
Contracts, not configs
A component is a contract paired with a handler. The schema is the source of truth: if the output schema has keys body and status, the component has exactly those output ports — no separate port declaration, nothing to drift.
Validate before you run
The graph validates statically from the definition alone — incompatible connections, missing connections, unresolved parameters, dangling edges, and cycles all surface before a single handler executes.
Fail at the boundary
Engines validate input against the contract before each handler and output after it. If your handler runs, its input has already passed the schema.
Portable by design
A WorkflowSpec is data, not code — no handlers, no executable strings, no secrets. The TypeScript engine ships today, an experimental Dart runtime proves the spec travels, and more engines are the point.
Agents as components
Agents are graph nodes with capabilities inlined on them — model, tools, MCP servers, memory, and skills — each a named contract resolved through the registry.
One spec. Every surface.
Author in the visual studio, run headless from the CLI, stream executions over the API, or serve whole workflows as MCP tools — the same portable spec underneath.
Studio · visual workflow editor
$ stargate run flow.json ✅ structure valid 🎉 completed · 1240ms
CLI · stargate run
HTTP API · runs stream over SSE
MCP · workflows served as tools
{ "componentName": "agent.default", "sourceType": "environment" }
WorkflowSpec · the artifact itself
The artifact is data. Nothing else travels.
A WorkflowSpec serializes graph topology, parameter bindings, and component references — never handlers, resolved runtime values, or secrets. Engines resolve contracts through the registry.
- Secrets stay env-var names — values never serialize
- No handlers, no executable strings in the artifact
- Validated at authoring, at load, and at every node boundary
{
"id": "wf_demo_001",
"name": "Ask the agent",
"nodes": [
{
"id": "agent-1",
"componentName": "agent.qa",
"parameters": { "instructions": "Answer briefly." },
"capabilities": {
"model": {
"name": "model.openai",
"parameters": {
"apiKey": {
"sourceType": "environment",
"envVar": "OPENAI_API_KEY"
}
}
}
}
}
]
}Questions, answered.
What is Stargate?
A workflow system built around reusable component contracts. A component pairs a schema contract — Zod I/O and parameter schemas held in a registry — with a language-specific handler, and a workflow is a directed graph of references to those components. It ships a visual studio editor, a NestJS HTTP API, and a CLI: stargate run, stargate studio, and stargate mcp serve.
What exactly is a component contract?
The component's I/O schemas plus its parameter specs. The schema is the source of truth: ports are projected from the schema's keys, never declared separately. Parameters resolve from static literals, environment-variable references, or JMESPath input paths — handlers only ever see the resolved value.
How is this different from n8n or Langflow?
Three design bets. Ports are named, stable, and derived from schemas instead of hand-wired. Workflows validate statically from the definition alone — incompatible connections, unresolved parameters, dangling edges, and cycles surface before anything runs. And the definition itself is a portable JSON artifact rather than an export welded to one runtime.
Can I run a spec outside TypeScript?
The TypeScript reference engine ships today, and an experimental pure-Dart runtime executes the same 40-case conformance suite — proof the spec is engine-neutral data. Multi-engine execution is the design goal, and more engines are planned.
Do specs contain secrets or code?
No. A WorkflowSpec is data: no handlers, no executable strings, no platform binaries. Secrets are referenced by environment-variable name — values never serialize. At run time the engine validates each node's input before the handler and its output after, so nothing crosses a boundary unchecked.
When can I use it?
Stargate is launching soon. Join the waitlist for early access and progress updates. Built by Concepta (conceptatech.com).
Be first through the gate.
Stargate is launching soon. Join the waitlist for early access and progress updates.