Competition Command Tower

A UiPath Maestro Case that governs coding agents, human gates, readiness audits, and exception recovery across parallel hackathon submissions.

Comment

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for URIAgent

Devpost Submission: Competition Command Tower

Updated: 2026-06-08 KST

Track Selection

  • Hackathon: UiPath AgentHack 2026
  • Selected track: UiPath Maestro Case
  • Rationale: The command tower is inherently exception-heavy case management — credential blockers, stale rules, timezone conflicts, and multi-agent routing are first-class citizens, not edge cases. Maestro Case is the only UiPath construct that handles dynamic multi-actor workflows where the path through each case is not known at design time.

Project Name

Competition Command Tower

Tagline

A UiPath Maestro Case that manages a portfolio of parallel hackathon competitions — automating intake, rule verification, multi-agent work routing, and human-approved submission through seven exception-aware stages.

Devpost Fields

Inspiration

Managing six simultaneous prize competitions produces compounding operational failures: rules change after initial read, deadlines conflict across PDT/EDT/KST time zones, platform credentials block specific competitions without stopping others, and work needs to route to different AI agents (Claude Code, Codex, Gemini) depending on the task type. A single missed requirement or unreviewed staleness flag can invalidate a submission that took days to build.

The inspiration was to build a workflow that treats each competition as a case with its own state, exception history, and human approval requirements — exactly the scenario UiPath Maestro Case was designed for.

What It Does

Competition Command Tower is a UiPath Maestro Case workflow that manages the full lifecycle of a hackathon competition entry:

  1. Contest Intake (Stage 1, Robot): Scrapes the official rules page, normalizes the deadline across time zones, flags timezone ambiguity, and creates a structured case record.

  2. Rule Verification (Stage 2, AI Agent): Checks freshness against the live page, resolves deadline conflicts, scores field confidence, and flags stale assumptions before work begins.

  3. Credential and Access Gate (Stage 3, Human Task): Presents a structured approval form to the operator's Action Center inbox. No credentials are used and no public artifacts are created until the operator explicitly approves.

  4. Work Routing (Stage 4, AI Agent): Decomposes the case into bounded tasks and dispatches each to the right agent lane (Codex for code, Claude Code for architecture and documentation, Gemini for alternatives, UiPath Robot for repo operations).

  5. Builder Execution (Stage 5, Coding Agents): Each agent executes its task, emits a result packet, and appends a worklog entry. Credential boundaries trigger a return to the gate; secret-unsafe artifacts are quarantined rather than advanced.

  6. Readiness Audit (Stage 6, AI Agent + Robot): Verifies every required Devpost asset (repo, license, README, video, deck, Automation Cloud proof), runs a secret safety scan, and produces a readiness packet.

  7. Submission Gate (Stage 7, Human Task): Presents the pre-filled Devpost submission form to the operator. Submission fires only on explicit SUBMIT approval. The gate receipt and final audit trail close the case.

The system handles exceptions at every stage: fetch failures, stale rules, credential blockers, missing video, and live platform unavailability all have named exception codes, defined resolution paths, and Action Center escalation.

How We Built It

We built a working, offline-runnable Maestro Case engine — not a design spec. The seven-stage case lifecycle, four exception classes (retry, re-entry, escalation), and the two blocking human gates are implemented as a stdlib-Python state machine with an append-only audit trail, driven by an interactive FastAPI dashboard where an operator clears the gates from the browser and watches the cases advance. The same code targets a live UiPath Automation Cloud tenant by setting five environment variables — make_backend() returns the UiPathMaestroBackend (OAuth client_credentials → Maestro process-instances + Action Center) when credentials are present, otherwise the LocalMaestroBackend used by the demo and tests. This is the SplunkRestBackend pattern: one interface, local runs offline, the cloud path is code-complete and credential-gated.

Build process:

  1. Implemented the case engine (case_engine.py): advance(), retry with exponential backoff, stage re-entry, escalation, and human-task gating that blocks the case until decide(). Every transition emits one AuditEvent.
  2. Implemented the seven stage handlers, the four named exception classes with detect+handle policies, the multi-agent routing table, and readiness scoring.
  3. Built the LocalMaestroBackend + UiPathMaestroBackend adapter and the make_backend() one-line switch (see docs/DEPLOY_RUNBOOK.md).
  4. Built the FastAPI dashboard (webapp/) with approve/defer/skip human-task endpoints, a liv

Built With

  • action-center
  • automation-cloud
  • claude-code
  • codex
  • fastapi
  • gemini-cli
  • github
  • python
  • uipath-maestro
Share this project:

Updates