It started with an engineering-capacity problem, not an AI demo.

The small work was consuming the important work.

Small upgrades, client-specific configuration changes and bug fixes were consuming engineering capacity that should have gone into architecture, product improvements and new features. Even with client behaviour designed as modular database configuration, the volume of changes stretched the team far enough that feature delivery sometimes moved into weekends.

The code change was often not the expensive part. A developer first had to reconstruct the application: dependencies, blockers, coding standards, files and methods distributed across the codebase. Missing one relationship could turn a locally correct change into a regression elsewhere.

Then the capability boundary moved.

Tool-using agents made a longer workflow plausible: inspect a ticket, recover project context, map the relevant repository surface, propose a plan, wait for approval, perform the work and return evidence.

The opportunity was broader than Turb0. The product idea was a virtual employee that could eventually take on bounded roles across the delivery cycle. The implemented proof focused on software-engineering work, where the complete loop could be tested without pretending every organizational role already existed.

Build the workflow, not a code-generating party trick.

t0rque was conceived as an engineering system that meets teams inside Jira, repositories and pull requests. The unit of value is not a clever response. It is responsibly moving a piece of work forward.

That decision shaped the architecture: a Python body for deterministic actions, a Hermes Agent brain for reasoning and tool use, persistent project memory, an inspectable plan, explicit human approval and evidence after execution.

Activity is easy to automate. Accountability is the design problem.

A working implementation made the argument concrete.

Akshay conceived the product, designed the system and built an active working prototype. It reads Jira work, retrieves and updates product context, inspects repositories, produces a plan, waits for approval, creates a branch, changes code, runs available local validation, reviews the result, captures browser evidence, opens a pull request and updates Jira.

A deliberately small public-safe demonstration changed a dashboard heading in a todo application. The task was ordinary by design; the test was whether the system would preserve the full engineering workflow around it rather than jumping from prompt to code.

Human approval is part of the architecture.

Before repository work begins, a person inspects the proposed plan and explicitly authorizes development. A second human boundary remains after proof of work, when the pull request is reviewed.

This is not an apology for incomplete automation. It is a deliberate boundary around consequential changes, uncertain context and the difference between producing code and accepting responsibility for it.

The demonstration earned a broader question.

Invoke leadership was impressed by the working demonstration and wanted to explore t0rque across teams. That expansion is currently on hold while production-readiness work remains unfinished and Akshay is committed to other delivery priorities.

The prototype still establishes the operating model: autonomy where repetitive work benefits from it, explicit control where judgment changes the consequence, and traceability across the whole piece of work.

Ambition is useful. An accurate status line is more useful.