A kitchen doesn't redesign the whole line when they add a new dish. They add a station. Same in flows. Started with three gates — build, test, vision. Behaviour and feel came later, each a single-file extension. Gates aren't hardcoded. They're sub-agents declared in YAML. Want a linting gate? Add a sub-agent with a linter. Security scan? Same pattern. Asset bundle size check? Write the tool, declare the agent, wire it in.
+A kitchen doesn't redesign the whole line when they add a new dish. They add a station. Same in flows. Started with three gates — build, test, vision. Behaviour and feel came later, each a single-file extension. Gates aren't hardcoded. They're sub-agents called from JavaScript flows. Want a linting gate? Add an agent() call with a linter. Security scan? Same pattern. Asset bundle size check? Write the tool, declare the agent, wire it in.
Self-Improving Kitchen
@@ -538,17 +538,17 @@
Flow 1 · 4 June, 18:32
-
/deep-implement — "Build the tinqs-gitea-read extension: list_org_repos, read_repo_file, list_repo_dir, search_repos." Nine steps, 14 minutes. Verdict: PASS. 31/31 vitest tests green, zero new TypeScript errors, session-level caching, path traversal protection. Every execute() body fully wired — no stubs, no placeholders. Like a saucier who doesn't just list ingredients but actually makes the sauce.
+
deep-implement — "Build the tinqs-gitea-read extension: list_org_repos, read_repo_file, list_repo_dir, search_repos." Nine steps, 14 minutes. Verdict: PASS. 31/31 vitest tests green, zero new TypeScript errors, session-level caching, path traversal protection. Every execute() body fully wired — no stubs, no placeholders. Like a saucier who doesn't just list ingredients but actually makes the sauce.
Flow 2 · 4 June, 19:04
-
/game-feature — "Make the player jump." Build: PASS. Tests: PASS. Behaviour/Feel/Visual: NOT RUN — no live game instance was reachable. The flow didn't silently skip the visual gate. It hard-stopped and reported honestly: "FAIL — the feature has not been verified in-game." This is the kitchen saying: "The dish is cooked, but nobody tasted it. I'm not sending it out."
+
game-feature — "Make the player jump." Build: PASS. Tests: PASS. Behaviour/Feel/Visual: NOT RUN — no live game instance was reachable. The flow didn't silently skip the visual gate. It hard-stopped and reported honestly: "FAIL — the feature has not been verified in-game." This is the kitchen saying: "The dish is cooked, but nobody tasted it. I'm not sending it out."
Flow 3 · 4 June, 19:49
-
/cto-infra — "Synthesize cost, stability, and VCS research into an AWS architecture decision." Four research streams fed into one CTO agent. Output: 14 requirements mapped to specific decisions, cost-vs-stability tradeoffs resolved with dollar figures, EC2+EBS over Fargate+EFS, RDS Multi-AZ mandatory, S3+CloudFront for LFS. Like an executive chef reading four menu proposals, reconciling them into one service, and pricing every plate.
+
cto-infra — "Synthesize cost, stability, and VCS research into an AWS architecture decision." Four research streams fed into one CTO agent. Output: 14 requirements mapped to specific decisions, cost-vs-stability tradeoffs resolved with dollar figures, EC2+EBS over Fargate+EFS, RDS Multi-AZ mandatory, S3+CloudFront for LFS. Like an executive chef reading four menu proposals, reconciling them into one service, and pricing every plate.
@@ -556,61 +556,59 @@
Dinner Rush Recovery: The Crash That Interrupted Service
Earlier today, a machine crash cut off a flow mid-stream — the kitchen lost power during dinner rush. Nineteen tests were left red. Contracts written, implementation half-done. Half-cooked dishes on every station.
-
I typed one slash command — the expediter reassembled the brigade:
+
I spawned the same flow with a different task:
-
/game-feature Finish the leftover jump & locomotion animation work — make the 19 FAILING tests GREEN.
+
tinqs flow run game-feature --task 'Finish the leftover jump & locomotion animation work -- make the 19 FAILING tests GREEN.'
-
What happened next: the team picked up exactly where the crash left off. Here's the recipe — the exact YAML that runs in production:
+
What happened next: the team picked up exactly where the crash left off. Here's the recipe — the exact JavaScript that runs in production:
-
name: game-feature
-description: Build a PLAYABLE game feature and prove it in the LIVE game.
-task_required: true
+// .pi/flows/flows/game-feature.flow.mjs
+export const meta = {
+ name: "game-feature",
+ description: "Build a PLAYABLE game feature and prove it in the LIVE game.",
+ task_required: true
+};
-steps:
- # G0: Pre-flight — validate vision CAN run before any build work
- - id: preflight
- agent: vision-preflight
- task: Check GEMINI_API_KEY is set AND game_frames reaches a live instance.
- If EITHER fails, STOP — vision is not optional.
+export default async function run({ task, flow }) {
+ // G0: Pre-flight — validate vision CAN run before any build work
+ await flow.agent("vision-preflight", {
+ task: "Check GEMINI_API_KEY is set AND game_frames reaches a live instance."
+ });
- # Context + plan
- - id: context
- agent: project-context-reader
- blockedBy: [preflight]
+ // Context + plan
+ const context = await flow.agent("project-context-reader");
+ const plan = await flow.agent("feature-planner", { context });
- - id: plan
- agent: feature-planner
- blockedBy: [context]
+ // TDD: write tests FIRST (different agent than implementer)
+ const testSuite = await flow.agent("test-author", { plan });
- # TDD: write tests FIRST (different agent than implementer)
- - id: test-author
- agent: test-author
- blockedBy: [plan]
+ // Implement
+ const source = await flow.agent("game-builder", { testSuite, plan });
- - id: implement
- agent: game-builder
- blockedBy: [test-author]
+ // G1–G5: Oracle gates run via parallel for speed
+ const gates = await flow.parallel([
+ flow.agent("build-verifier", { source }),
+ flow.agent("test-runner", { source }),
+ flow.agent("behavioral-prober", { source }),
+ flow.agent("feel-judge", { source }),
+ flow.agent("animation-vision-judge", { source })
+ ]);
- # G1–G5: Oracle gates (build, tests, behaviour, feel, visual)
- - id: build → agent: build-verifier
- - id: tests → agent: test-runner
- - id: behavior → agent: behavioral-prober (drives LIVE game via drive_game)
- - id: feel → agent: feel-judge (apex, airtime, latency, rise/fall)
- - id: visual → agent: animation-vision-judge (multimodal gemini-2.5-flash)
+ // Self-recurring fix-loop: bounded loop back to implement with evidence
+ const MAX_RETRIES = 3;
+ for (let attempt = 1; attempt <= MAX_RETRIES; attempt++) {
+ const decision = await flow.agent("flow-decision", { gates });
+ if (decision.verdict === "pass") break;
+ if (attempt === MAX_RETRIES) {
+ const fixed = await flow.agent("game-builder", { source, failures: decision.evidence });
+ }
+ }
- # Self-recurring fix-loop: bounded loop back to implement with evidence
- - id: fix-loop
- type: agent-loop-decision
- agent: flow-decision
- loop_target: implement
- exit_target: report
- max_iterations: 3
+ // Final judge: one honest verdict
+ return flow.agent("game-judge");
+}
- # Final judge: one honest verdict
- - id: report
- agent: game-judge
-
-
Eighteen steps, seven cooks, five inspection points, one head chef. Triggered by a single order ticket.
+
Eight logical steps, seven cooks, five inspection points, one head chef. Triggered by a single spawn.
Here's how the brigade actually worked. The vision-preflight agent — the chef who checks the gas is on before anyone starts cooking — verified GEMINI_API_KEY was set and game_frames could reach the live game. Both green in under a second. Without this, the whole kitchen would prep for an hour only to discover the oven doesn't work.
@@ -624,29 +622,29 @@ steps:
Not a Demo
-
This flow is a file at .pi/flows/flows/game-feature.yaml. I trigger it by typing /game-feature in Pi. It dispatches agents, runs gates, loops on failures, reports a verdict. There is no dashboard with drag-and-drop. There is a YAML file and a slash command. That's the whole product.
+
This flow is a file at .pi/flows/flows/game-feature.flow.mjs. I trigger it by running tinqs flow run game-feature or clicking Run Flow on the dashboard. It dispatches agents, runs gates, loops on failures, reports a verdict. The dashboard at :33634 is the control plane — spawn, steer mid-run, inspect state. That's the whole product.
-
The Menu: Flows Are Slash Commands
-
Every flow becomes a slash command — the menu you read to the expediter. .pi/flows/flows/game-feature.yaml → /game-feature. You don't invoke a pipeline from a terminal. You order a dish in conversation.
+
The Menu: Flows at Your Fingertips
+
Every flow lives in .pi/flows/flows/*.flow.mjs and is spawnable by name. You run tinqs flow run <name> [task] or click Run Flow on the dashboard.
-
"Add wall-running" is not a CLI flag. It's natural language. The flow reads it, wires it through the agents, routes it through the gates. The YAML is the recipe. The conversation is the context.
+
"Add wall-running" becomes the task argument. The flow reads it, wires it through the agents, routes it through the gates. The JavaScript is the recipe. The conversation provides the context.
The menu I call from daily:
- - /game-feature — "add a double-jump" or "fix the 19 red tests" → brigade assembles, cooks, inspects, plates
- - /deep-implement — "build the gitea-read extension" → research → plan → implement → test → review → judge
- - /cto-infra — "reconcile cost, stability, and VCS research into architecture decisions" → 4 research streams → 1 synthesis agent → 14 requirements mapped to decisions
- - /flows:new — "I need a flow that..." → the Flow Architect reads the agent catalog, selects cooks, designs the recipe, writes the YAML
+ - game-feature — "add a double-jump" or "fix the 19 red tests" → brigade assembles, cooks, inspects, plates
+ - deep-implement — "build the gitea-read extension" → research → plan → implement → test → review → judge
+ - cto-infra — "reconcile cost, stability, and VCS research into architecture decisions" → 4 research streams → 1 synthesis agent → 14 requirements mapped to decisions
+ - flows:new — "I need a flow that..." → the Flow Architect reads the agent catalog, selects cooks, designs the recipe, writes the
.flow.mjs
The Pass: How Agents Hand Off Work
In a real kitchen, cooks don't shout instructions across the room. They place finished plates on the pass. The expediter reads the ticket, checks the plate, routes it to the next station or to the dining room. Nobody yells. Nobody grabs someone else's pan.
-
Flows work the same way. Agents never talk to each other directly. When the game-builder finishes, it doesn't ping the test-runner. It calls finish({ summary: "...", artifacts: "...", files: "..." }) — placing its work on the pass. The flow engine — the expediter — records it and routes it. The next agent receives exactly the inputs wired in the YAML: ${{result.game-builder.summary}}, ${{result.game-builder.files}}.
+
Flows work the same way. Agents never talk to each other directly. When the game-builder finishes, it returns a result object — placing its work on the pass. The flow engine — the expediter — records it and routes it. The next agent receives the return value directly from await flow.agent("game-builder").
@@ -655,11 +653,11 @@ steps:
What Actually Happens
-
Agent A → finish({verdict: "pass", findings: ["coyote_time=100ms"]}) → engine records → Agent B receives ${{result.A.findings}} via inputs: block. No chatter. Structured handoff.
+
Agent A returns { verdict: "pass", findings: ["coyote_time=100ms"] } → flow engine records it → Agent B receives the result as a direct return value of await flow.agent("A"). No chatter. Structured handoff.
-
Why? Because unstructured chatter is how hallucination cascades start. Agent A confidently states something wrong. Agent B builds on it. Agent C compounds it. Three agents later, they're collectively wrong about a file that doesn't exist, and nobody can trace where the error came from. The pass — structured result-passing with typed outputs — makes every handoff auditable, verifiable, and debuggable.
+
Why? Because unstructured chatter is how hallucination cascades start. Agent A confidently states something wrong. Agent B builds on it. Agent C compounds it. Three agents later, they're collectively wrong about a file that doesn't exist, and nobody can trace where the error came from. The pass — structured result-passing via typed return values from each agent() call — makes every handoff auditable, verifiable, and debuggable.
Pi itself is built for solo interactive work: you ask, it does, you review. The orchestration layer I wrote on top inverts that. Pi becomes the kitchen. The flow engine becomes the expediter. Agents become line cooks who place plates on the pass, never shouting across the room.
@@ -700,17 +698,17 @@ outputs: [summary, files]
You are a game developer. Task: ${{task}}
Context: ${{input.context}}
-
Flows are YAML DAGs that wire agents together. I have about 15–20 flows running across different domains:
+
Flows are JavaScript modules (.flow.mjs) that coordinate agents with real control flow. I have about 15–20 flows running across different domains:
- - Game dev: /game-feature, /review, /bug-hunt, /refactor
- - Design: /concept-art, /sound-design (plans → ElevenLabs generation → judge evaluates with other models)
- - Marketing: /brand-image, /trailer-clip (Sora 2 video generation → vision judge)
- - Infra: /ci-fix, /deploy-check, /tstudio-jobs (action runners on AWS Lambda, workspace management)
+ - Game dev: game-feature, review, bug-hunt, refactor
+ - Design: concept-art, sound-design (plans → ElevenLabs generation → judge evaluates with other models)
+ - Marketing: brand-image, trailer-clip (Sora 2 video generation → vision judge)
+ - Infra: ci-fix, deploy-check, tinqs-jobs (action runners on AWS Lambda, workspace management)
- Meta: A flow that periodically reads and improves the other flows — yes, flows that edit flows
-
The setup is not a product you install. It's a stack: Pi as the agent harness, custom extensions as the tool layer, markdown agents as the role layer, YAML flows as the orchestration layer. The whole thing lives in .pi/flows/. Version-controlled. CI-tested. Slash-command invoked.
+
The setup is not a product you install. It's a stack: Pi as the agent harness, custom extensions as the tool layer, markdown agents as the role layer, JavaScript flows as the orchestration layer. The whole thing lives in .pi/flows/. Version-controlled. CI-tested. Spawned via tinqs flow run or the dashboard.
The Recipe vs. The Technique
"Do you define the process with these trees, or do the agents freestyle?" Both. The recipe says what to make and in what order. The technique is how each cook executes their station.
@@ -718,7 +716,7 @@ Context: ${{input.context}}
The Recipe (Rigid)
-
The flow YAML is the recipe. It says: first the prep cook dices onions, then the saucier makes the base, then the grill cook sears the protein. After every station, the plate hits the pass for inspection. This order is not negotiable. A cook cannot skip the inspection because they feel confident. The inspection runs. Period.
+
The flow's JavaScript is the recipe. It says: first the prep cook dices onions, then the saucier makes the base, then the grill cook sears the protein. After every station, the plate hits the pass for inspection. This order is not negotiable. A cook cannot skip the inspection because they feel confident. The inspection runs. Period.
The Technique (Autonomous)
@@ -730,7 +728,7 @@ Context: ${{input.context}}
The Meta-Kitchen
-
And when a recipe is wrong? Another flow improves it. A meta-flow reads performance data, spots bottlenecks — "the feel gate keeps failing because the cook doesn't know the jump velocity threshold" — edits the YAML to wire that threshold into the builder's inputs, and commits the change. Flows that edit flows. The kitchen that renovates itself between services.
+
And when a recipe is wrong? Another flow improves it. A meta-flow reads performance data, spots bottlenecks — "the feel gate keeps failing because the cook doesn't know the jump velocity threshold" — edits the .flow.mjs to pass that threshold into the builder's inputs, and commits the change. Flows that edit flows. The kitchen that renovates itself between services.
diff --git a/posts/agent-harness.md b/posts/agent-harness.md
index fbe8ffe..5e6a76a 100644
--- a/posts/agent-harness.md
+++ b/posts/agent-harness.md
@@ -24,7 +24,7 @@ Every agent harness, regardless of domain, needs five things:
**Tools.** What the agent can actually do beyond generating text. A CLI that takes screenshots, checks service health, and loads project context. API wrappers for git, CI, image generation. Without tools, the agent is a very articulate oracle that can't touch anything.
-**Context.** Which project this is. Who's asking. What machine they're on. What services are reachable. A single CLI call — `tstudio identity` — returns all of this in 100ms. No re-reading the README. No "what repo are we in?"
+**Context.** Which project this is. Who's asking. What machine they're on. What services are reachable. A single CLI call — `tinqs identity` — returns all of this in 100ms. No re-reading the README. No "what repo are we in?"
**Guardrails.** What the agent must never do. No merging to main without review. No pushing to public repos without approval. No running destructive commands. The harness enforces these at the platform layer, not in the prompt. Prompts can be ignored. Platform gates cannot.
@@ -44,7 +44,7 @@ LangChain, CrewAI, and AutoGen are built for web apps. They assume text-in, text
Our harness runs on [Tinqs Studio](https://tinqs.com), built on a Gitea fork with game-specific features. The key pieces:
-**The CLI** — a single Go binary. One command (`tstudio identity`) gives the agent full project context in 100ms. Screenshots, cloud vision, health checks — all subcommands of the same binary.
+**The CLI** — a single Go binary. One command (`tinqs identity`) gives the agent full project context in 100ms. Screenshots, cloud vision, health checks — all subcommands of the same binary.
**The soul file** — a markdown document in the repo root. The agent reads it on session start. It defines values, scope, and behavioural rules. The same soul file works in Cursor, Claude Code, or any tool that reads markdown.
diff --git a/posts/studio-cli.md b/posts/studio-cli.md
index e2e620b..fbfb3e0 100644
--- a/posts/studio-cli.md
+++ b/posts/studio-cli.md
@@ -12,11 +12,11 @@ author_role: "CTO & Developer, Tinqs"
---
Every AI agent session starts the same way: cold. The agent doesn't know what project this is, who's asking, what tools are available, or what happened yesterday. You spend the first five minutes re-explaining context.
-Our CLI solves this in 100ms. One command — `tstudio identity` — and the agent knows everything. The binary is 15MB, has zero runtime dependencies, and runs on every machine in the studio.
+Our CLI solves this in 100ms. One command — `tinqs identity` — and the agent knows everything. The binary is 15MB, has zero runtime dependencies, and runs on every machine in the studio.
## The identity command (100ms)
-When an agent starts, the first thing it calls is `tstudio identity`. The output:
+When an agent starts, the first thing it calls is `tinqs identity`. The output:
- **Soul file** — the agent's persistent identity, values, operating principles
- **Company context** — team members, roles, what the company does
@@ -26,7 +26,7 @@ When an agent starts, the first thing it calls is `tstudio identity`. The output
This data lives in markdown files in the docs repo. Any machine on the network can read it. The agent goes from blank to fully contextual in under a second.
-This started as a convenience tool for humans. It became the single most important function in our stack. Every agent session — Cursor, Claude Code, Pi — starts with `tstudio identity`. Without it, every conversation begins with "let me explain the project." With it, the agent already knows.
+This started as a convenience tool for humans. It became the single most important function in our stack. Every agent session — Cursor, Claude Code, Pi — starts with `tinqs identity`. Without it, every conversation begins with "let me explain the project." With it, the agent already knows.
## Screenshots and cloud vision
@@ -38,7 +38,7 @@ This is how you file bugs without typing. Look at the game, tell the agent what'
## Health checks
-`tstudio doctor` runs a comprehensive check:
+`tinqs doctor` runs a comprehensive check:
- Is the git platform reachable and authenticated?
- Is the game server running?
@@ -55,7 +55,7 @@ Cross-compilation is trivial. We build Windows, Mac (arm64 + amd64), and Linux b
## What we learned
-**The CLI is the API for AI agents.** What started as a human convenience tool became the primary interface for agents. Every session starts with `tstudio identity`. The agent's "hands and eyes" — screenshots, vision, health checks — are subcommands of the same binary.
+**The CLI is the API for AI agents.** What started as a human convenience tool became the primary interface for agents. Every session starts with `tinqs identity`. The agent's "hands and eyes" — screenshots, vision, health checks — are subcommands of the same binary.
**One binary beats ten scripts.** Scripts rot. They have different shells, different PATH assumptions, different error handling. A compiled binary either works or it doesn't. It ships with dependencies baked in. It doesn't care if your Python is 3.9 or 3.12.
diff --git a/studio-cli.html b/studio-cli.html
index 447b316..57a759b 100644
--- a/studio-cli.html
+++ b/studio-cli.html
@@ -265,9 +265,9 @@
Every AI agent session starts the same way: cold. The agent doesn't know what project this is, who's asking, what tools are available, or what happened yesterday. You spend the first five minutes re-explaining context.
-
Our CLI solves this in 100ms. One command — tstudio identity — and the agent knows everything. The binary is 15MB, has zero runtime dependencies, and runs on every machine in the studio.
+
Our CLI solves this in 100ms. One command — tinqs identity — and the agent knows everything. The binary is 15MB, has zero runtime dependencies, and runs on every machine in the studio.
The identity command (100ms)
-
When an agent starts, the first thing it calls is tstudio identity. The output:
+
When an agent starts, the first thing it calls is tinqs identity. The output:
- Soul file — the agent's persistent identity, values, operating principles
- Company context — team members, roles, what the company does
@@ -276,13 +276,13 @@
- Service status — which URLs are live and reachable
This data lives in markdown files in the docs repo. Any machine on the network can read it. The agent goes from blank to fully contextual in under a second.
-
This started as a convenience tool for humans. It became the single most important function in our stack. Every agent session — Cursor, Claude Code, Pi — starts with tstudio identity. Without it, every conversation begins with "let me explain the project." With it, the agent already knows.
+
This started as a convenience tool for humans. It became the single most important function in our stack. Every agent session — Cursor, Claude Code, Pi — starts with tinqs identity. Without it, every conversation begins with "let me explain the project." With it, the agent already knows.
Screenshots and cloud vision
The CLI can capture any window from outside the process. No in-game overlay, no rendering pipeline integration. OS-level capture — GDI+ on Windows, screencapture on Mac.
A photo command sends the screenshot to a cloud vision model. The agent says "take a photo of the game" and gets back: "The player character is standing near a half-built hut. Three palm trees to the left. The terrain has a visible seam between two biomes."
This is how you file bugs without typing. Look at the game, tell the agent what's wrong. It takes a screenshot, describes what it sees, and creates an issue with both the description and the image attached. Keyboard-free bug reporting.
Health checks
-
tstudio doctor runs a comprehensive check:
+
tinqs doctor runs a comprehensive check:
- Is the git platform reachable and authenticated?
- Is the game server running?
@@ -294,7 +294,7 @@
Go compiles to a single static binary. No Python virtualenvs, no Node.js version managers, no DLL hell on Windows. The same binary runs on a gaming PC, a designer's MacBook, and a CI runner in AWS.
Cross-compilation is trivial. We build Windows, Mac (arm64 + amd64), and Linux binaries from a single CI workflow. Push a tag, CI builds all three, uploads to S3. The binary is 15MB, starts in under 100ms, has zero runtime dependencies.
What we learned
-The CLI is the API for AI agents. What started as a human convenience tool became the primary interface for agents. Every session starts with tstudio identity. The agent's "hands and eyes" — screenshots, vision, health checks — are subcommands of the same binary.
+The CLI is the API for AI agents. What started as a human convenience tool became the primary interface for agents. Every session starts with tinqs identity. The agent's "hands and eyes" — screenshots, vision, health checks — are subcommands of the same binary.
One binary beats ten scripts. Scripts rot. They have different shells, different PATH assumptions, different error handling. A compiled binary either works or it doesn't. It ships with dependencies baked in. It doesn't care if your Python is 3.9 or 3.12.
Cloud vision is underrated for game dev. Sending a screenshot to a vision model sounds gimmicky. In practice, it's the fastest way to document visual bugs. "The tree is floating 2m above the terrain" is much faster to communicate when the AI is looking at the same screen.
Agent cold starts are the real problem. Without the identity system, every session starts with the agent asking "what project is this?" With it, the agent knows everything in 100ms. That's the difference between an AI assistant and an AI team member.