Ting workflows: A2A agent cards, Open Workflow Spec definitions, a minimal Rust executor, and OpenSpec + Datalog gates
- Rust 100%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
|
|
||
| catalog | ||
| executor | ||
| LICENSE | ||
| README.md | ||
Ting workflows
The definition and execution layer that Ting's console presupposes: workflow definitions, the reusable parts they share, and the small executor that runs them. Epic: Ting/workflows#1.
Rulings (Larandar, 2026-09-06)
- Agents are A2A Agent Cards, sourced as YAML, served as JSON. They live in
larandar/agents.lar— a personal card per persona underagents/<persona>/, generic seat cards and their preset underseats/(larandar/agents.lar#6). One card per seat kind; running instances are contexts on that card, never cards of their own. This repository holds no card. - A workflow is an Open Workflow Specification (CNCF, DSL 1.0) definition — the deployment
layer: each step binds a card by reference, a model route, inputs, authority, and a gate. Its
inputschema is what Dispatch renders; Dispatch only starts a workflow. - The executor is ting's own, in Rust, deliberately small: parse and validate on the spec's
Rust SDK, provision what each step's agent needs, start steps over
ting-a2a, evaluate gates, emit run state. No general engine. - Code gates are OpenSpec + Datalog, evaluated by the executor and callable by agents.
- The UI never legislates for the harness: everything the console shows about a run is what the executor or the harness emitted.
Layout
catalog/— the public, reusable parts: the versioned function library (functions/<name>/<version>/function.yaml), seat and gate templates, sub-workflows such as the landing gate. A part enters the catalog only when a second workflow reuses it.executor/— the Rust crate that is the executor.
The OpenSpec capabilities that describe these (contracts.ting.agent-card,
contracts.ting.workflow-definition) live in Ting/contracts.