Tina

Tina is an autonomous factory. It takes in clear work items from Jira, Github issues, etc and work on them to produce work that's relatively easily verified by a person.

pip install tina-cli

The track in that recording is examples/bug-triage/ — the config, the skill, and what each key does.

How is Tina different from an agent harness?

Tina is an orchestrator of sort.

It selects a work item, claims it, and calls an agent harness once with a one-shot prompt that I call a track.

The agent harness does the individual work item. Currently, I use pi, because it's small and relatively stable. I may use a different one in the future.

So what's the value of doing this approach instead?

With an agent harness, you have to sit there and steer it. Even if you have one shot prompts, you need to put those prompts in there.

For work items that are very self similar, you can instead make what I can a track.

Think of it like a runbook or a guide. You take several examples of work you have already done once and use them to describe to the agent what it should do.

Then upstream from this system in your ticketing system, you make work items for it.

Downstream from this system PRs get made or Confluence docs get write or whatver other outcome you want.

You just write tickets instead of driving around your agent to get work done.

This approach scales your attention better than having 5 simultaneous agent sessions running simultaenously, especially you enter production situations where you're quickly drowned by the amount of work coming your way.

High-level track approach

A track is Source -> Skill -> Result.

harness = "pi"
executor = "local"

[harnesses.pi]
command = ["pi", "-p", "@{prompt_file}"]

[bug]
source = "github"
repo = "acme/api"
labels = ["bug"]            # or the full query = "repo:acme/api is:issue ..."
track = "triage"
result = "github:issue-comment"

A basic workflow:

tina validate                        # the config and every skill, statically
tina doctor                          # credentials, queries, harness, executor
tina dispatch --track bug --limit 5
tina run --track bug --item 4821
tina status --track bug

status derives both counts from the track's own query — once as dispatch runs it, and once with its no:assignee clause swapped for the bot — so they are two halves of one question and Tina keeps no state to go stale.

An external scheduler calls dispatch. Tina does not own scheduling — Cloud Scheduler, EventBridge, k8s CronJob, systemd timers, and GitHub Actions all work without Tina knowing about them.

Design

• Orchestration only. Tina never writes a result. The agent does, with its own tools.
• Harness agnostic. pi, Claude Code, and others are subprocess adapters. Tina never parses harness stdout — the agent writes outcome.json to a path Tina provides.
• No persistent state. The tracker is the ledger. Workers claim items, and claimed items drop out of the query.
• Control plane in a file. Pause and throttle live in a control file read fresh every dispatch, so whoever holds the pager can stop the factory without a deploy. Per-track max_concurrency and a governor seam sit beside it.
• No tracks included. Tracks are skills, installed with napoln at image build time. tina tracks --format json lists them so infrastructure can be derived from the same file the runtime reads.

Documentation

Development

See CONTRIBUTING.md for the full guide.

just is the task runner (brew install just).

just setup    # Install all dependencies
just check    # Format check, lint, type check, tests
just fmt      # Auto-fix formatting and lint
just test     # Run tests

Without just:

uv sync --all-extras       # Install all dependencies
uv run ruff format --check # Format check
uv run ruff check          # Lint
uv run ty check            # Type check
uv run pytest              # Run tests

License

MIT