I spent The Agent Harness Hackathon 2026 building that agent for WeMakeDevs and TrueFoundry, with Qodo on every substantive PR. Think Iron Man’s butler, except this one cannot merge your pull request even if it really wants to.

The judged demo is one mission — not the whole product:

“Jarvis, I have my client demo at 3 PM. Make sure I’m ready.”

That run is the hardest loop I could prove in a week: Calendar for context, Gmail for the client’s real requirements, GitHub for an exact revision, Daytona for fail-before / pass-after verification, then a human checkpoint before a pull request exists.

Demo: youtube.com/watch?v=piE_bitPRzE

Repo: sahil1330/jarvis-ops-agent

The problem I actually cared about

Most “agents” still wait for app-by-app commands: open Calendar, search Gmail, inspect GitHub, run tests, open a PR. That is a chatbot with extra steps, and you are still the glue.

I wanted the opposite. If I am late, underprepared, or staring at a client thread and a broken upload path at the same time, I should be able to say what I need to be true. The agent should plan, gather evidence, verify software claims instead of assuming them, and refuse to send mail, move a meeting, or publish code until I say so.

Jarvis is that personal ops layer. Gmail, Calendar, GitHub, memory, sandbox, and voice are tools. The product is the loop.

How the week actually unfolded

I did not start with the 3 PM demo. The first merged slices were a narrower personal assistant: Gmail and Calendar behind a dedicated MCP, a TrueForge streaming runtime, and a control center that showed the live trace and approval cards.

That foundation is PR #1, PR #2, and PR #3. The interesting part was not “call Gmail.” It was not letting the browser become an authority. The UI can Allow or Deny a pending TrueForge call. It cannot send the email itself. If your frontend can hit Gmail directly, you do not have an agent. You have a form with extra latency.

Then the product had to feel like a person in the room, not a log viewer:

• Accessibility and honest system labels, not colour-only dots (PR #4)

• Tool failures that stay visible instead of collapsing into “Tool call completed” (PR #7)

• Neural voice, then Realtime speech, then speaking while tools run so the room is not silent for a minute (PRs #8–#14)

• Explicit memory: remember / forget / recall, never silent logging of a whole conversation (PR #8)

Only after that did I pivot the agent from a late-arrival helper into an objective-driven harness. PR #19 wrote the contract. PR #21 made the operating rules real: Context → Requirements → Verify → Action. A green pre-existing test suite is not proof that the client’s edge case works. Green tests that never upload a 5 MB PDF are just very confident.

TrueForge is the harness, not the wrapper

TrueForge runs the loop:

• persistent sessions and streamed turn events

• two isolated MCP servers (Google Workspace, GitHub)

• dynamic subagents for independent Calendar/Gmail work and for engineering

• Daytona sandbox / Code Mode for untrusted code and tests

• requireApprovalForTools for send_email, move_calendar_event, and every GitHub write

• askUserQuestions when a required detail cannot be discovered

• context compaction for large tool responses

The control center is a renderer. OpenAI Realtime is a voice renderer. Neither has Gmail, Calendar, GitHub, memory, sandbox, or approval authority.

Credentials stay compartmentalized. Google OAuth never leaves the Google MCP. The GitHub PAT never leaves the GitHub MCP. Daytona gets source and a task, not secrets. The sandbox is allowed to break the demo product. It is not allowed to walk off with my refresh token.

That is the difference between “we used an agent SDK” and “the harness is doing the work.”

The demo mission, on purpose

For judging I needed one mission that cannot be faked with a pretty UI.

A synthetic Atlas client asks for a roughly 5 MB PDF resume upload, job recommendations, and analytics. Healthy main supports that with a 6 MiB ceiling. A throwaway branch, demo/client-regression, lowers only that ceiling to 1 MiB. Baseline tests stay green there because the 5 MB case is not pre-authored.

Jarvis has to:

1. Find the meeting.

2. Read the client thread.

3. Snapshot the exact GitHub SHA.

4. Run the green suite.

5. Derive the missing reproduction from the email, not from a planted failing test.

6. Watch the 413.

7. Patch the minimum.

8. Prove fail-before / pass-after, then the broader suite.

9. Stop on publish_verified_fix.

10. Wait for an explicit “Approve it.” Ambiguous phrases like “okay” do not count. “Sounds good” is how production incidents start.

11. Open a jarvis/... branch and PR. Never merge.

This is the pause. The 413 already failed, the patch already passed, and Jarvis still will not create the PR until a human continues:

Verified in the sandbox. Still waiting. That is the whole point.

If the sandbox was merely created, verification is not done. If publication failed, the UI says so.

It did fail, once, on an invalid jarvis/ branch name. The control center did not hide it. Status stayed Completed with issues, Jarvis retried with a legal ref, and PR #31 opened. No merge. I would rather show a red box and a real PR than a green lie.

A lying demo would have cropped this. A trustworthy one leaves the error in the shot.

The GitHub page is the same story outside the control center: Open, into demo/client-regression, fail-before 413 and pass-after in the body, and still not merged.

Jarvis can open the PR. It cannot merge it. That is a feature.

The live loop is also slow. Daytona plus a real reproduce-and-verify pass does not fit in three minutes of wall clock. The submission video is a cut of a real run, not a mocked success path. If I submitted the uncut rehearsal, judges would age a full Daytona sandbox lifetime.

What was actually hard

Sending an email is easy. Making the semantics trustworthy is not.

I had to reconstruct TrueForge approval references without giving the browser write power. An accepted approval cannot become retryable after a later stream failure. Delayed speech has to bind to the checkpoint it was captured for. Refresh recovery is only the paused human checkpoint, not a fake replay of in-flight sandbox events. GitHub publication has to recheck a stale base SHA and clean up a branch if PR creation fails.

Qodo was not a checkbox. High findings got fixed. On the GitHub permission surface it caught a head filter that GitHub requires as owner:branch. On the UI it caught markdown links hidden from assistive tech. Both shipped as fixes, then a follow-up review, then merge (PR #30). Earlier, a Git Data commit response that did not include tree.sha would have published from the wrong tree (PR #29). Thank you, Qodo, for being the friend who asks “are you sure that SHA is a tree?”

Smaller, dumber bugs taught me as much: TrueForge standalone returning plain-text OK! and the UI declaring the harness offline; the setup script unwrapping agents.list() twice; Realtime SDP sent as the wrong multipart type. Those are the difference between a demo that works on the author’s laptop and a demo a judge can actually run.

How I built it (AI disclosure)

AI coding assistance was used throughout. Most of the implementation was done with OpenAI Codex in focused PRs. Later integration and review work, including the user-input checkpoint and GitHub permission surface, used Cursor. I reviewed the architecture, tests, safety boundaries, Qodo findings, and merge decisions. If I cannot explain a boundary, it does not belong in the submission.

Every substantive change went through a GitHub PR, Qodo review, and CI. That is slower than pushing to main. It is also why I trust the approval path more than I would after a weekend of unreviewed diffs.

What I would tell myself on Monday morning

1. Put the trust boundary in first. If the UI can write, you do not have an agent harness. You have a dashboard with extra latency.

2. Measure the conversational path. Silent tool time is a product bug even when the trace looks busy.

3. Do not plant the failing test you want the agent to “discover.” If the suite already encodes the client case, the demo is theatre.

4. Treat Qodo High findings as production bugs. The ones that looked pedantic were the ones that would have failed live.

Jarvis is not finished. This week I proved the loop on Gmail, Calendar, GitHub, memory, and a sandbox — one judged mission, not a finished assistant. Next I want to keep adding workspaces and platforms the same way: Slack, docs, more repos, whatever I actually live in, each behind the same MCP + approval boundary. I also want it off the browser: a real desktop and mobile application, not a website, that wakes on a word the way a proper assistant should. The wake word would open the conversation. It would still not be allowed to send mail or open a PR until I approve the exact call.

A proper personal ops agent is not a bigger prompt. It is more licensed tools, still unable to write the outside world until I say so.

I did not ship a public URL on purpose. The judged runtime binds to loopback: the orchestrator has no end-user login and it pays for STT, TTS, and Realtime, so putting it on the internet would be an open tab on my API bill. Gmail and Calendar also use sensitive Google OAuth scopes. A public client would need Google’s brand and app verification, not just a Cloud Run box. npm run doctor treats a non-loopback bind as a blocker for the same reason. A hosted multi-user product would need that Google verification, a real application auth boundary, and per-user credentials that never enter Daytona. This week’s job was a trustworthy local agent, not a fake production deploy. What I did finish is something that can take an outcome, show its work, and wait.

That is the license I wanted to give a model: act, but not unsupervised.

Built for The Agent Harness Hackathon 2026 by WeMakeDevs × TrueFoundry, with Qodo on the review trail.

If you share this, tag @wemakedevs, @truefoundry, and @qodo_ai.

Architecture notes: docs/architecture.md