blog/posts/studio-cli.md

title, slug, date, description, og_description, og_image, excerpt, author, author_initials, author_role

title	slug	date	description	og_description	og_image	excerpt	author	author_initials	author_role
One Binary to Rule Them All: Building a Studio CLI	studio-cli	2026-05-18	A single Go binary that handles machine identity, screenshots, cloud vision, and health checks. The glue that makes AI agents useful across a multi-machine game studio.	A single Go binary for machine identity, screenshots, cloud vision, and AI agent coordination.	https://www.tinqs.com/img/og-cover.jpg	A single Go binary that gives AI agents context about who you are, what machine you're on, and what services are reachable. Screenshots, cloud vision, health checks --- one install, every machine.	Ozan Bozkurt	OB	CTO & Developer, Tinqs

Every machine in our studio runs the same Go binary. It knows who you are, what machine you're on, and what services are reachable. It takes screenshots, sends them to cloud vision, and runs health checks. This is the glue that makes AI agents actually useful in a multi-machine game studio.

Why Build a CLI

When you have multiple machines across several people, two operating systems, and AI agents that need context about the environment they're running in, the glue becomes the hardest part. Which machine is this? What services are reachable? Is the game running? Can I take a screenshot of what the developer is looking at?

We tried shell scripts. A setup.sh for Mac, a setup.ps1 for Windows, a check-services.sh for health checks, a screenshot.py that never worked on Windows. They drifted. They broke. Nobody updated them.

So we built one Go binary that does everything.

The Identity System

The most important command is identity. When an AI agent starts a new session --- Cursor, Claude Code, any tool --- the first thing it does is call this command. The output tells the agent:

• The soul file --- the agent's persistent identity, values, and operating principles
• Company context --- team members, roles, what the company does
• Machine context --- hostname, OS, which repos are cloned, what services are running
• Ecosystem --- other repos and their purpose
• Service status --- which URLs are live and reachable

This solves a fundamental problem with AI agents: cold starts. Every new chat window, every new agent tab, every new session is a blank slate. The agent doesn't know what project this is, who's asking, or what infrastructure exists. One CLI call gives it full context.

The data lives in markdown files in the docs repo --- the source of truth. Any machine on the network can read it.

Screenshots and Vision

The CLI can capture any window from outside the process. No in-game overlay, no rendering pipeline integration. It uses the OS-level window capture API --- works on Windows (via GDI+) and Mac (via screencapture).

A photo command does the same thing but sends the screenshot to a cloud vision model for analysis. The agent says "take a photo of the game" and gets back a structured description: "The player character is standing near a half-built hut. There are 3 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, and the agent takes a screenshot, describes what it sees, and creates an issue with both the description and the image attached.

Health Checks

A doctor command runs a comprehensive health check:

• Is the git platform reachable? Can we authenticate?
• Is the game server running?
• Are all expected repos cloned and on the right branch?
• Are required tools installed and at the right version?

The output is a green/yellow/red table. If something's wrong, the agent knows immediately and can diagnose or escalate. This is essential for unattended agent sessions --- the agent can verify its environment before starting work.

Why Go

Go compiles to a single static binary with no runtime dependencies. 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, done.

The binary is 15MB. It starts in under 100ms. It has zero runtime dependencies. For a tool that AI agents call on every session start, speed matters.

What We Learned

The CLI is the API for AI agents. When we started, this was a convenience tool for humans. It became the primary interface for AI agents. The identity command was originally "nice to have" --- now it's the single most important function in our stack. Every agent session starts with it.

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 its 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 and getting back a structured description 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 write when the AI is looking at the same screen you are.

Agent cold starts are the real problem. Without the identity system, every new session starts with the agent asking "what project is this?" and the human re-explaining context. With it, the agent knows everything in 100ms. That's the difference between an AI assistant and an AI team member.

---

The CLI is part of Tinqs Studio --- our game development platform that brings git hosting, AI agent tools, and team workflows together. Every time we find ourselves writing a script that needs to work on multiple machines, we add a subcommand instead. One binary that makes the studio work, whether the operator is human or AI.