Taskmaster — Event-Driven AI Project Operator

Live PostgreSQL-backed project state: 17 tasks across Todo, Doing, Review, and Done, with blockers, priorities, deadlines, and assignees.
Production integrations powering Taskmaster: GitHub, Vertex AI with Gemini 3.5 Flash, Google Cloud Pub/Sub, Neon PostgreSQL, and Slack.
Live Command Center: project risk signals, autonomous actions, human approval gates, PostgreSQL verification, and Slack delivery.

Inspiration

One problem stood out to us while building software: a lot of project work happens after the “main” event.

A pull request gets merged, but someone still has to figure out what needs to happen next. Maybe a QA task is missing, another task is blocked, one developer is overloaded, or the team needs to be notified. Most tools record these things, but they still depend on a person noticing the problem and doing the follow-up.

We wanted to build an agent that could actually take responsibility for that follow-through.

What it does

Taskmaster is an event-driven AI Project Operator. Instead of waiting for a user to ask what should happen next, it can react to a real project event and work in the background.

For example, when a GitHub pull request is merged, Taskmaster verifies the event, sends it through Google Cloud Pub/Sub, and processes it in a Cloud Run worker. Gemini 3.5 Flash then looks at the actual project state in PostgreSQL — tasks, dependencies, blockers, deadlines, workload, and activity — and decides what follow-up is needed.

It can create safe follow-up work automatically, while more consequential actions, such as changing task ownership, are stopped for human approval.

After an action is executed, Taskmaster checks the database again to make sure the expected change really happened. The result is then recorded as a Proof of Work record and can be communicated to Slack.

The workflow is:

Event → Understand → Decide → Act → Verify → Communicate

How we built it

We built the application around a PostgreSQL-backed project state and a durable event-driven workflow.

The main stack is Gemini 3.5 Flash, Google ADK, Vertex AI, Cloud Run, Google Cloud Pub/Sub, Neon PostgreSQL, GitHub Webhooks, Slack, and Google Secret Manager.

The GitHub webhook verifies incoming requests with HMAC-SHA256 before persisting and publishing the event. Pub/Sub then decouples event ingestion from agent execution, so the webhook does not have to wait for the AI workflow to finish.

Gemini has read-only access to project inspection tools. The application policy layer controls what the agent is actually allowed to do:

-> create_subtask → AUTO -> send_slack_message → AUTO -> reassign_task → REVIEW

This separation was important to us because we did not want the model itself to decide what actions are safe.

Challenges we ran into

The difficult part was not getting Gemini to generate a plan. The difficult part was making an agent that could safely operate on real state.

We had to deal with duplicate GitHub deliveries, asynchronous worker execution, retries, interrupted workflows, approval pauses, and making sure a successful response actually meant that the database changed correctly.

We also had to separate AI decisions from deterministic application rules. That became especially important for actions like task reassignment, where an incorrect autonomous decision could affect another person.

Finally, we had to make the whole workflow observable. A judge — or a real user — should be able to see what triggered an action, why it happened, what policy allowed it, whether it succeeded, and what was verified.

Accomplishments that we're proud of

The biggest thing we are proud of is that Taskmaster goes beyond generating recommendations.

A real GitHub event can trigger a background workflow that reaches Gemini through Vertex AI, performs an actual project action, verifies the resulting PostgreSQL state, and reports the outcome.

We also built a human approval boundary into the workflow instead of treating every agent decision as automatically safe.

The final system has a deterministic demo environment with 17 tasks, 8 dependencies, 4 blockers, and 3 deadline risks, and our automated test suite passes 96/96 tests covering the workflow, policy enforcement, webhook security, idempotency, approvals, mutations, and verification.

What we learned

We learned that building an agent is much more than connecting an LLM to a few APIs.

The model can decide what should happen, but the surrounding system has to control what it is allowed to do, remember what already happened, recover from failures, and verify the result.

The biggest lesson for us was that “the agent said it worked” is not proof that it worked. That is why we made post-action verification and the Proof of Work layer part of the product instead of treating them as debugging tools.

What's next for Taskmaster — Event-Driven AI Project Operator

This version is intentionally focused on engineering project follow-through and the GitHub workflow we built for the hackathon.

The next step would be to extend the same execution model to more project events and integrations while keeping the same policy and verification boundaries.

The goal is not to give an agent unrestricted control over a project. The goal is to make it useful enough to take care of routine follow-through while keeping humans in control of decisions that actually matter.