FJX

The Problem

Human–AI collaboration on software usually grows a second system: a side channel for coordination, a bespoke task store, an out-of-band memory layer that only the agents understand. Now there are two sources of truth to keep in sync, and the humans can no longer read what the agents are doing in the tools they already use.

No second source of truth. No out-of-band coordination layer.

The Approach

FJX is an agent-accelerated forge: humans and LLM agents collaborate through the same artifacts — issues, pull requests, comments, labels, and assignees — on a Forgejo instance. Rather than inventing specialized tooling, it leans on existing forge primitives so every workflow stays legible to both sides, and so the whole system improves as the models improve instead of accreting complexity to compensate for them.

• Roles with scoped authority. PM, DEV, and QA are distinct Forgejo accounts, each limited to a narrow set of actions. PM gets the most autonomy, acting on the Owner's (the human in the loop) behalf; DEV is focused and constrained; QA is deliberately adversarial, there to challenge the work rather than rubber-stamp it.
• Forge-native workflow. Slash commands and a shared label system drive the state machine. There is no secondary system to reconcile — reading the issue tracker is reading the system.
• Agents are swappable. Adapters normalize Codex and Claude session logs into the same event stream, and all context lives in the forge, so swapping an agent in or out costs nothing — the work history is captured the way a human's would be.

Supervision

A supervisor (fjx supervise) runs agent "ticks" — for PM, a sweep of all issue activity since the last tick; for DEV and QA, the next highest-priority issue assigned to them. Each tick spawns the agent in a Docker container with an enforced timeout, and the full transcript is persisted whether the run succeeds, fails, or exits silently — a container that dies without a word still lands in telemetry as a failed run rather than a mystery. The supervisor runs one-shot for a specific role and issue, or as a daemon for "AFK mode," where development is driven entirely through issues and comments.

Observability

Agents you can't inspect are agents you can't trust with autonomy, so the supervisor treats its own behavior as a first-class data source. Every run emits telemetry — JSONL shards per branch, compacted into a queryable store — that a management UI turns into answers to the questions that actually matter when supervising agents:

• Which runs failed or stalled, and on what?
• Where is tool use inefficient — excessive calls, repeated context gathering?
• What is each role's token spend actually buying?

This is the feedback loop for the prompts themselves: when the telemetry shows an agent re-discovering how to use the fjx CLI every tick, that's a prompt bug with a paper trail.

Where it stands

The system is working as designed and is the daily harness for three or four of my own projects across Deno, Go, and Rust stacks. The role workflow, supervisor, adapters, telemetry pipeline, and management UI all work today. Areas still in need of improvement:

• Bootstrapping. Documenting and automating the setup of a Forgejo instance to support FJX, so standing one up doesn't require me.

• Model routing. Adapters cover Codex and Claude today; the next step is smart routing — fast, inexpensive models for simple tasks, frontier models for complicated ones.

• Prompt & tool refinement. The agents still spend too much effort gathering context and re-discovering how to use the fjx utility every tick — telemetry makes this visible; now it needs fixing.

• AFK mode mileage. I'm still one-shotting the supervisor for specific roles and issues to a) observe how the agents are behaving, and b) gain more confidence in the guardrails before leaning on unattended operation.

• Garbage collection. Even at this small scale, disk usage needs to stay stable — build artifacts and package caches across the Deno, Go, and Rust projects will need regular cleanup.