Tinqs Agent
130 lines
11 KiB
Markdown
130 lines
11 KiB
Markdown
---
|
|
title: "From Local to Cloud: Agents That Run While You Sleep"
|
|
slug: cloud-agents
|
|
date: "2026-05-26"
|
|
description: "A Go orchestrator inside Tinqs Studio spawns coding agents in RPC mode, manages worker pools, creates git worktrees, waits for CI, and opens PRs — all while you sleep."
|
|
og_description: "Cloud agents: a Go orchestrator that spawns coding agents, manages worker pools, and delivers PRs overnight."
|
|
og_image: "https://www.tinqs.com/img/og-cover.jpg"
|
|
excerpt: "A Go orchestrator inside Tinqs Studio that spawns coding agents in RPC mode, manages worker pools, creates git worktrees, waits for CI, and opens PRs — all while you're asleep."
|
|
author: "Ozan Bozkurt"
|
|
author_initials: "OB"
|
|
author_role: "CTO & Developer, Tinqs"
|
|
---
|
|
We built an orchestrator in Go that runs coding agents on our servers, on our repos, while nobody is watching. It spawns agents in RPC mode, manages worker pools, creates isolated git worktrees, waits for CI to pass, and opens pull requests. Your backlog runs overnight. You wake up to PRs.
|
|
|
|
## Why the Dashboard Wasn't Enough
|
|
|
|
The local dashboard is great for workday use. Queue up tasks while you're at your desk, monitor them in a browser tab, review PRs as they land. But it has a hard limit: your machine has to be on. When you go home, the agents stop. When you close your laptop, the queue freezes. When Windows decides it's time for an update and reboots at 3am, your overnight batch of 12 tasks is gone.
|
|
|
|
More importantly, the local dashboard doesn't integrate with your team's workflow. It doesn't know about your CI pipeline, your branch protection rules, your code review assignments. It's a personal tool, not a team tool.
|
|
|
|
We needed agents that run **on infrastructure, not on laptops.** Agents that spawn when there's work and shut down when there isn't. Agents that understand the full lifecycle from issue assignment to merged PR, not just "generate this code and stop."
|
|
|
|
So we built an orchestrator.
|
|
|
|
## The Orchestrator: Go, RPC, and Worker Pools
|
|
|
|
The orchestrator is a Go service that runs inside Tinqs Studio. It manages a pool of coding agents and feeds them work. Here's how it fits together.
|
|
|
|
### RPC Mode: Agents as Subprocesses
|
|
|
|
The coding agent supports an RPC mode --- a JSON protocol over stdin/stdout. No terminal UI, no interactive prompts, no human in the loop. You send a JSON command on stdin, the agent processes it, and you get JSON responses and streaming events on stdout.
|
|
|
|
```json
|
|
{"type": "prompt", "message": "Fix the null pointer in VegetationGrid.ActivateChunk() and add a unit test"}
|
|
```
|
|
|
|
The agent reads the codebase, plans the change, calls tools, runs tests, and streams progress back as JSON events. When it's done, the session stops. No human needed.
|
|
|
|
The orchestrator spawns one agent subprocess per active job. Each agent is isolated --- its own process, its own working directory, its own session state. If an agent crashes, the orchestrator captures the error, cleans up, and marks the job as failed. Nothing leaks between jobs.
|
|
|
|
### Worker Pools: Don't Spin Up One Agent per Task
|
|
|
|
Spawning a new process for every task would be slow and wasteful. The orchestrator maintains a pool of idle agent processes, ready to accept work.
|
|
|
|
When a task comes in, the orchestrator picks an idle worker from the pool, assigns the task, and the worker goes to work. When the task completes, the worker returns to the pool. If there's no idle worker and the pool isn't at capacity, the orchestrator spawns a new one. If the pool is full, the task queues.
|
|
|
|
The pool size is configurable. We default to 3 concurrent workers --- enough to parallelize independent tasks without overwhelming CI or hitting rate limits. For teams with heavier workloads, bump it to 5 or 8. The limit is your CI throughput and your API budget, not the orchestrator.
|
|
|
|
### Git Worktrees: Isolation Without Forking
|
|
|
|
Every job gets its own git worktree. Not a clone --- a worktree. A clone copies the entire repository, which for our game repo means copying 12GB of LFS objects. A worktree checks out a new working directory on a new branch, sharing the same `.git` directory as the main clone. It takes under a second.
|
|
|
|
The workflow:
|
|
|
|
1. Orchestrator receives a task with a repository ID
|
|
2. Creates a worktree on a new branch named `agent/<task-id>`
|
|
3. Spawns or assigns a worker pointed at that worktree
|
|
4. Worker runs the task --- reads, writes, commits, pushes
|
|
5. When done (or failed), worktree is cleaned up
|
|
|
|
Worktrees solve the isolation problem without the overhead of full clones. Two agents can work on the same repo simultaneously, on different branches, with zero file conflicts. The orchestrator handles the lifecycle --- create the worktree before the job starts, remove it after the job ends.
|
|
|
|
## The Full Lifecycle: From Issue to Merged PR
|
|
|
|
A cloud agent job doesn't end when the code is written. The orchestrator shepherds the task from assignment to merge. Here's the full lifecycle:
|
|
|
|
**1. Task intake.** A task is created --- either manually through the dashboard, automatically from an issue, or scheduled from a backlog. The task specifies the repository, the prompt, and optionally constraints (target branch, reviewers, labels).
|
|
|
|
**2. Worktree creation.** The orchestrator creates an isolated worktree on a branch named `agent/<task-id>`. If the repo has CI hooks, the branch name triggers the pipeline.
|
|
|
|
**3. Agent execution.** The worker receives the prompt via RPC, reads the codebase, writes code, runs tests locally. If local tests fail, the agent iterates until they pass. If they can't pass after a configured number of attempts, the job fails early --- no point pushing broken code.
|
|
|
|
**4. Push and CI.** When local tests pass, the agent commits and pushes. The orchestrator detects the push and starts polling CI status. It doesn't just fire and forget --- it waits.
|
|
|
|
**5. CI monitoring.** The orchestrator polls the CI pipeline every 30 seconds. If CI fails, it feeds the failure logs back to the agent. The agent reads the logs, fixes the issue, commits, and pushes again. This loop repeats until CI passes or the agent exhausts its retry budget.
|
|
|
|
**6. PR creation.** When CI is green, the orchestrator opens a pull request with the agent's summary --- what changed, why, and testing notes. It assigns reviewers based on repo configuration and adds labels.
|
|
|
|
**7. Cleanup.** The worktree is removed. The worker returns to the pool. The job status updates to "awaiting review."
|
|
|
|
All of this happens without human intervention. A task submitted at 11pm can be a merged PR by the time you check your notifications at 8am.
|
|
|
|
## CI Integration: Closing the Loop
|
|
|
|
The CI loop is where cloud agents earn their keep. A local agent can write code and run tests, but it can't push and wait for CI. It can't see that the Windows build failed because of a path separator issue while the Linux build passed. It can't adjust and try again.
|
|
|
|
The orchestrator can. When CI fails, the orchestrator:
|
|
|
|
1. Fetches the failure logs from the CI system
|
|
2. Appends them to the agent's session as context
|
|
3. Sends a follow-up prompt: "CI failed with these errors. Fix them."
|
|
4. The agent reads the logs, identifies the issue, and makes a fix
|
|
5. Commit, push, poll CI again
|
|
|
|
We've seen agents fix CI failures that would take a human 20 minutes to diagnose --- missing imports in test files, platform-specific path handling, version mismatches in dependency files. The agent doesn't know these things innately, but given the CI logs and the codebase, it figures them out.
|
|
|
|
The retry budget is configurable. We default to 3 CI retries per task. If CI fails 3 times and the agent can't fix it, the job is marked "needs human" with the full failure context. A human reviews, fixes, and the agent doesn't burn credits looping on an unfixable problem.
|
|
|
|
## The Agents Tab: Coming to tinqs.com
|
|
|
|
All of this is managed through a new Agents tab, coming to every repository on Tinqs Studio. It's a single view for everything agent-related on your repo:
|
|
|
|
- **Job queue** --- pending, running, completed, failed tasks
|
|
- **Agent sessions** --- live session output with file diffs
|
|
- **Cost tracking** --- per-task and aggregate API spending
|
|
- **Configuration** --- pool size, model selection, CI retry budget, reviewer assignments
|
|
- **History** --- past jobs with full logs and outcomes
|
|
|
|
The Agents tab turns the orchestrator from a developer tool into a team tool. Any team member can submit tasks, monitor progress, and review results. The PM can queue up backlog items. The designer can request asset changes. The lead developer can review PRs the agents opened overnight.
|
|
|
|
It's not launching as a separate product. It's a tab on your repo, next to Issues, Pull Requests, and Actions. Agents are part of the development workflow, not a bolt-on.
|
|
|
|
## What We've Learned
|
|
|
|
**RPC mode is the right abstraction for headless agents.** Early versions of the orchestrator tried to script the interactive agent --- sending keystrokes, parsing terminal output. It was fragile and slow. RPC mode is a proper API: structured input, structured output, streaming events. The orchestrator and the agent speak the same language.
|
|
|
|
**Worker pools save cold-start time.** Spawning a new agent process for every task adds 2--3 seconds of startup overhead --- loading config, warming caches, reading the soul file. With a pool of idle workers, tasks start instantly. The overhead matters when you're running 50 tasks overnight.
|
|
|
|
**CI polling is more reliable than webhooks.** We started with webhook-based CI integration --- CI notifies the orchestrator when a build completes. Webhooks get dropped, delayed, or delivered out of order. Polling every 30 seconds is simpler, more reliable, and the latency difference is irrelevant for overnight batch work.
|
|
|
|
**Git worktrees are a superpower.** Before worktrees, parallel agents meant multiple clones or complex branching strategies. Worktrees give you isolation for free. One command, no copy, no wait. When a job finishes, the worktree disappears. When a new job starts, a fresh worktree appears. No stale state, no cleanup burden.
|
|
|
|
**Cloud agents complement local agents, not replace them.** The dashboard is for interactive work during the day --- pair-programming, quick fixes, exploration. The orchestrator is for batch work overnight --- backlog processing, large-scale refactors, scheduled maintenance. They're two modes of the same tool, not competitors.
|
|
|
|
---
|
|
|
|
Cloud agents aren't science fiction. They're a Go service, a worker pool, and an RPC protocol running on our infrastructure, doing real work on real repos. The local dashboard made agents useful during the day. The cloud orchestrator makes them useful around the clock.
|
|
|
|
We're building all of this as part of [Tinqs Studio](https://tinqs.com) --- a game development platform that brings together git hosting, AI agent tools, and creative workflows. The Agents tab is rolling out to repositories this quarter. If you want agents working on your backlog while you sleep, that's where they'll live.
|