rewrite: refresh all blog posts for public audience
Merged overlapping posts: - forking-gitea + fork-dont-build → one post about the fork philosophy - fal-image-generation + image-generation-fal → one post about AI art pipeline Rewrote all posts with external/public voice: - Stronger hooks, concrete examples, punchier language - agentic-workflow: restructured around soul files + skills + numbers - agent-harness: clearer framing of 'what an agent harness is' - cloud-harness: tighter narrative about overnight agents - godot-optimisation: same depth, sharper opening - pre-commit-agent: clearer architecture, cost breakdown - studio-cli: reframed around identity/cold-start problem - blog-visual-upgrade: tightened the restyle story 10 posts total (9 markdown + 1 hand-authored HTML)
This commit is contained in:
+38
-111
@@ -1,151 +1,78 @@
|
||||
---
|
||||
title: "Tinqs Studio Is an Agent Harness for Game Dev"
|
||||
title: "What an Agent Harness Is and Why Game Dev Needs One"
|
||||
slug: agent-harness
|
||||
date: "2026-05-25"
|
||||
description: "An agent harness gives AI agents identity, memory, tools, and guardrails. Tinqs Studio is one built specifically for game development --- git, 3D preview, image generation, and a CLI that makes every session a warm start."
|
||||
og_description: "Tinqs Studio is an agent harness for game dev --- identity, skills, vision, git, and creative tools in one platform."
|
||||
description: "A raw AI model is a brain without hands, eyes, or memory. An agent harness gives it identity, tools, context, and guardrails — and game development needs one built for binary assets, visual pipelines, and spatial systems."
|
||||
og_description: "Agent harnesses give AI identity, memory, and tools. Game dev needs one that understands 3D assets."
|
||||
og_image: "https://www.tinqs.com/img/og-cover.jpg"
|
||||
excerpt: "An agent harness gives AI agents identity, memory, tools, and guardrails. Tinqs Studio is one built for game development."
|
||||
excerpt: "A raw AI model is stateless. An agent harness wraps around it and provides identity, memory, tools, context, and guardrails. Here's why game development needs its own."
|
||||
author: "Ozan Bozkurt"
|
||||
author_initials: "OB"
|
||||
author_role: "CTO & Developer, Tinqs"
|
||||
---
|
||||
An agent harness is the layer between a raw AI model and a useful team member. It gives the agent identity, memory, tools, and guardrails. Tinqs Studio is an agent harness built specifically for game development.
|
||||
Open Claude or ChatGPT right now and ask it to review your last PR. It'll say "I don't have access to your repository." Ask it to take a screenshot of your game. It'll say "I can't interact with your operating system." Ask it what you were working on yesterday. It'll say "I don't have memory of previous conversations."
|
||||
|
||||
## What Is an Agent Harness?
|
||||
A raw AI model is a brain without hands, eyes, or memory. An **agent harness** is the layer that gives it all three — plus identity, tools, and guardrails. And game development needs one that understands binary assets, visual pipelines, and spatial systems.
|
||||
|
||||
A raw AI model --- Claude, GPT, Gemini --- is powerful but stateless. It doesn't know who you are, what project you're working on, what tools are available, or what happened yesterday. Every session is a cold start. Every conversation begins with "let me explain the project..."
|
||||
## What a harness provides
|
||||
|
||||
An agent harness solves this. It wraps around the model and provides:
|
||||
Every agent harness, regardless of domain, needs five things:
|
||||
|
||||
- **Identity** --- who the agent is, what it values, how it should behave
|
||||
- **Memory** --- what happened in previous sessions, what was decided, what failed
|
||||
- **Tools** --- what the agent can actually do beyond generating text
|
||||
- **Context** --- what project this is, who's asking, what infrastructure exists
|
||||
- **Guardrails** --- what the agent must never do, what requires human approval
|
||||
**Identity.** Who the agent is, what it values, how it should behave. Not "you are a helpful assistant" — that's generic and unmoored. A soul file that says "you're working on Ariki, a survival colony sim. The team is four people. Never push to main without review. Prefer existing conventions." Identity creates consistency across sessions.
|
||||
|
||||
Without a harness, you have a chatbot. With one, you have a team member.
|
||||
**Memory.** What happened last session. What decisions were made. What failed and why. Without memory, every conversation is a cold start — "let me explain the project..." Memory stored as markdown in git means it's version-controlled, diffable, and human-readable. When something goes wrong, you `git log` instead of debugging a vector database.
|
||||
|
||||
## Why Game Dev Needs Its Own Harness
|
||||
**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.
|
||||
|
||||
Generic agent harnesses exist --- LangChain, CrewAI, AutoGen. They're built for web apps, data pipelines, and customer support. Game development has different problems:
|
||||
**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?"
|
||||
|
||||
**Assets are binary.** A web developer's PR is a text diff. A game developer's PR is a 150MB GLB file. Generic harnesses don't know how to preview 3D models, manage LFS bandwidth, or review binary assets.
|
||||
**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.
|
||||
|
||||
**The pipeline is visual.** Game dev goes from concept art to 3D model to rigged character to in-engine asset. Each step uses different tools --- image generators, 3D modellers, auto-riggers, game engines. An agent harness for game dev needs to orchestrate this entire chain.
|
||||
## Why generic harnesses fail for game dev
|
||||
|
||||
**Scale is physical.** A web app's complexity is in business logic. A game's complexity is in geometry --- 12km worlds, 155 vegetation prototypes, 576 terrain regions, 2000 crowd instances. The agent needs to understand spatial systems, GPU memory, and frame budgets.
|
||||
LangChain, CrewAI, and AutoGen are built for web apps. They assume text-in, text-out. Game development is different in ways that break those assumptions:
|
||||
|
||||
**The team is small and cross-functional.** A 4-person game studio has no dedicated DevOps, no dedicated artist, no dedicated PM. The harness needs to fill all those gaps, not just one.
|
||||
**Assets are binary.** A web PR is a text diff. A game PR is a 150MB GLB file with textures, rigging, and animations. You can't review it without seeing it. Our harness renders 3D models in the browser during code review — rotate, zoom, check materials. The artist pushes, the lead inspects, no downloads required.
|
||||
|
||||
## How Tinqs Studio Works as a Harness
|
||||
**The pipeline is visual.** Concept art → 3D model → rigged character → in-engine asset. Each step uses different tools. The harness needs to orchestrate image generators, 3D modellers, auto-riggers, and game engines as a single workflow — not as five separate API calls the human has to stitch together.
|
||||
|
||||
Tinqs Studio is a platform built on a [Gitea fork](forking-gitea) with game-specific features layered on top. But the git platform is just the foundation. The harness is everything around it.
|
||||
**Scale is physical.** A web app's complexity is in business logic. A game's complexity is in geometry — 12km worlds, 155 vegetation types, 2,000 crowd instances. The agent needs to understand spatial systems, GPU memory budgets, and frame timing. "Add more RAM" isn't an answer when you have 8GB of VRAM.
|
||||
|
||||
### Identity: Soul Files
|
||||
**The team is small and cross-functional.** Four people. No dedicated DevOps, no dedicated artist, no dedicated PM. The harness fills all those gaps, not just one.
|
||||
|
||||
Every agent session starts by loading a soul file --- a markdown document that defines the agent's persistent identity. Not just "you are a helpful assistant" but specific values, knowledge scope, and behavioural rules.
|
||||
## The toolchain that makes it work
|
||||
|
||||
The soul file means the agent behaves consistently whether it's triaging bugs at 9am or generating concept art at midnight. It knows what repos exist, who the team members are, what the game is about, and what decisions have been made. Identity isn't cosmetic --- it's the difference between an agent that asks "what project is this?" and one that says "I see the vegetation grid was updated yesterday, want me to check the cache eviction?"
|
||||
Our harness runs on [Tinqs Studio](https://tinqs.com), built on a Gitea fork with game-specific features. The key pieces:
|
||||
|
||||
### Memory: Markdown Files in Git
|
||||
**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.
|
||||
|
||||
Agent memory is plain markdown files in a git repository. No vector databases, no proprietary stores. The agent reads its memory on session start, updates it during work, and commits changes back.
|
||||
**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.
|
||||
|
||||
This is deliberately low-tech. Markdown in git gives you version history, branching, merge conflict resolution, and human readability for free. When memory goes wrong --- and it will --- you can `git log` to see what changed and `git revert` to fix it.
|
||||
**Skills** — markdown playbooks for specific workflows. Image generation, concept art pipeline, 3D model creation, video generation. Each skill is a procedure the agent follows. Write once, use forever.
|
||||
|
||||
### Tools: The CLI
|
||||
**3D preview** — click a `.glb` file in a PR and rotate the model in your browser. 22 formats supported. This alone transformed our review process — nobody approves a binary diff blind anymore.
|
||||
|
||||
A [single Go binary](studio-cli) gives every agent access to:
|
||||
**Guardrails** — agents can file issues, draft announcements, generate assets, and write code. They cannot merge, deploy, or push to public repos without human approval. Branch protection rules enforced at the git platform layer.
|
||||
|
||||
- **Identity loading** --- full project context in 100ms
|
||||
- **Screenshots** --- capture any window from outside the process
|
||||
- **Cloud vision** --- send screenshots to a vision model, get structured descriptions
|
||||
- **Health checks** --- verify services, repos, and tools are working
|
||||
- **Service status** --- which URLs are live, what's reachable
|
||||
## The cold-start problem, solved
|
||||
|
||||
The CLI is the agent's hands and eyes. Without it, the agent can only read and write text. With it, the agent can see the game running, photograph bugs, and verify infrastructure.
|
||||
Every AI agent session starts blank. Most teams solve this with long system prompts — but when your context is 200 markdown files, 15 skills, and 3 years of project history, you can't paste all of that.
|
||||
|
||||
### Skills: Teachable Workflows
|
||||
The harness uses staged loading:
|
||||
|
||||
Skills are markdown playbooks that teach agents specific procedures. Instead of hoping the model figures out how to generate concept art or create a 3D model, you write the steps once:
|
||||
1. **CLI identity call** (100ms) — soul file, company context, machine info, service status
|
||||
2. **Memory file** (instant) — cross-session context from the docs repo
|
||||
3. **Skills** (on demand) — loaded only when the task matches a skill name
|
||||
4. **Repo context** (on demand) — files read as needed, not all upfront
|
||||
|
||||
- [Image Generation](../skills/image-generation.md) --- generate game art with fal.ai Flux using a [4-layer prompt pattern](fal-image-generation)
|
||||
- [Concept Art Pipeline](../skills/concept-art-pipeline.md) --- from design brief through 2D art to 3D model export
|
||||
- [3D Model Generation](../skills/tripo-browser-workflow.md) --- Tripo Studio text-to-3D and image-to-3D
|
||||
- [Video Generation](../skills/sora2-video.md) --- trailer clips with OpenAI Sora 2
|
||||
Agent goes from cold to fully contextual in under a second. No "let me explain the project." No re-reading onboarding docs. Just start working.
|
||||
|
||||
Skills compound. Every playbook you write makes the agent more capable. After six months, our agents handle art generation, competitive research, video production, project management, and code review --- all from markdown files.
|
||||
## The bet
|
||||
|
||||
### Git Platform: 3D Preview and LFS
|
||||
The gap between "I have an AI model" and "I have an AI team member" is infrastructure. Identity, memory, tools, context, guardrails. For game development, that infrastructure needs to understand binary assets, visual pipelines, and spatial systems.
|
||||
|
||||
The [Gitea fork](forking-gitea) underneath handles the game-specific git problems:
|
||||
|
||||
- **3D asset preview** --- rotate GLB/FBX/STL files in the browser during code review
|
||||
- **LFS-first workflows** --- auto-tracking for game file extensions, storage dashboards
|
||||
- **OAuth2 SSO** --- one login for git, tools, and the game
|
||||
- **22 format support** --- GLB, FBX, OBJ, STL, 3DS, PLY, and more via O3DV
|
||||
|
||||
### Guardrails: Human-in-the-Loop
|
||||
|
||||
The harness defines what agents can and cannot do:
|
||||
|
||||
- Agents can file issues, draft announcements, generate assets, write code
|
||||
- Agents **cannot** merge code, deploy builds, push to public repos, or post to external channels without human approval
|
||||
- The [public blog repo](https://tinqs.com/tinqs/blog) requires human-approved merge requests --- agents can propose changes but a person must review
|
||||
|
||||
This isn't a limitation --- it's a feature. The agent handles volume; the human handles judgement.
|
||||
|
||||
## The Cold Start Problem
|
||||
|
||||
The biggest problem with AI agents in production isn't capability --- it's context. Every new session is blank. The agent doesn't know what happened yesterday, what's in progress, or what tools are available.
|
||||
|
||||
Most teams solve this with long system prompts. That works until your context is 200 markdown files, 15 skills, and 3 years of project history. You can't paste all of that into a system prompt.
|
||||
|
||||
The harness solves this with **staged loading**:
|
||||
|
||||
1. **CLI identity call** (100ms) --- loads soul file, company context, machine info, service status
|
||||
2. **Memory file** (instant) --- loads cross-session context
|
||||
3. **Skills** (on demand) --- loaded only when the task matches a skill name
|
||||
4. **Repo context** (on demand) --- read files as needed, not all upfront
|
||||
|
||||
The agent goes from cold to fully contextual in under a second. No "let me explain..." No re-reading the same onboarding doc. Just start working.
|
||||
|
||||
## What Makes This Different from LangChain
|
||||
|
||||
LangChain, CrewAI, and similar frameworks are **code-first**. You define agents in Python, chain them with function calls, and deploy them as services. They're powerful for building AI products.
|
||||
|
||||
Tinqs Studio is **file-first**. Agents are defined in markdown. Skills are markdown. Memory is markdown. Identity is markdown. Everything is in git, readable by humans, editable without code changes, and version-controlled.
|
||||
|
||||
This matters for game teams because:
|
||||
|
||||
- **Non-engineers can contribute.** The designer writes a skill for concept art. The PM writes a skill for sprint planning. No Python required.
|
||||
- **Everything is auditable.** `git log` shows who changed what, when, and why. Memory changes are commits. Skill updates are diffs.
|
||||
- **It works with any AI tool.** The same soul files and skills work in Cursor, Claude Code, or any tool that reads markdown. You're not locked into one framework.
|
||||
|
||||
## The Stack
|
||||
|
||||
| Layer | What | How |
|
||||
|-------|------|-----|
|
||||
| **Identity** | Soul files, company context | Markdown in git, loaded via CLI |
|
||||
| **Memory** | Cross-session context | Markdown in git, updated by agents |
|
||||
| **Skills** | Teachable workflows | Markdown playbooks, loaded on demand |
|
||||
| **Tools** | CLI, screenshots, vision | Go binary, one install per machine |
|
||||
| **Git** | 3D preview, LFS, SSO | Gitea fork with game-specific features |
|
||||
| **Creative** | Image gen, 3D models, video | fal.ai, Tripo, Sora 2 via skills |
|
||||
| **Guardrails** | Human approval gates | Branch protection, MR requirements |
|
||||
|
||||
## Getting Started
|
||||
|
||||
If you want to build your own agent harness for game dev:
|
||||
|
||||
1. **Start with a soul file.** Write 50 words about your project's identity, values, and scope. Put it in your repo root as `SOUL.md`.
|
||||
2. **Write one skill.** Pick the workflow you repeat most --- concept art generation, bug triage, build verification --- and write the steps as markdown.
|
||||
3. **Build a CLI identity command.** Even a shell script that prints "project name, repos, services" gives your agent a warm start.
|
||||
4. **Put everything in git.** Not a database, not a SaaS tool. Git. You already have it.
|
||||
|
||||
The rest --- 3D preview, LFS management, OAuth SSO, creative pipelines --- you can add as you need it. Or use [Tinqs Studio](https://tinqs.com), where we've already built it.
|
||||
We're betting that specialised harnesses beat generic ones. A harness built for game dev — with 3D preview, LFS management, and creative pipelines — will outperform a general-purpose agent framework on game dev tasks. Not because the AI is smarter, but because it has the right hands, eyes, and memory for the job.
|
||||
|
||||
---
|
||||
|
||||
An agent harness isn't a product category yet. But it should be. The gap between "I have an AI model" and "I have an AI team member" is infrastructure --- identity, memory, tools, context, guardrails. For game development, that infrastructure needs to understand binary assets, visual pipelines, and spatial systems. That's what we're building.
|
||||
*Tinqs Studio is an agent harness for game development — git hosting, AI agents, creative pipelines. Open for teams. We're building [Ariki](https://arikigame.com) with the same tools.*
|
||||
|
||||
Reference in New Issue
Block a user