FootyApp

Turn one message into a fully organised match. FootyAgent is a multi-agent AI on AWS Bedrock that books the pitch, rallies the players, and balances fair teams — less admin, more football for all.

Comment

FootyAgent

Inspiration

Organizing a casual football match sounds simple until you actually do it. Someone has to check who is available, find a venue, negotiate time and price, adjust the format based on the number of players, handle late replies, keep everyone informed, and still make the teams fair. Most of this coordination happens manually through chat groups, fragmented messages, and last-minute decisions.

FootyAgent was inspired by that real-world friction. We wanted to build an AI assistant that behaves less like a generic chatbot and more like a practical match organizer: one that can understand a natural-language goal, ask for missing information, coordinate different parties, track progress, and produce a final confirmed match plan.

For the AWS hackathon, our goal was to show how agentic AI can solve a concrete coordination problem end-to-end, while keeping the human organizer in control.

What it does

FootyAgent is a multi-agent football match organizer. The user starts by writing a goal such as:

Organize a football match next Friday after 21:00. Flexible format: 5v5, 6v6, or 7v7. Invite players from the Regulars group. Prefer indoor if weather is bad. Budget is around EUR 8 per player.

From there, FootyAgent:

  • Parses the organizer's goal using Amazon Bedrock.
  • Asks clarification questions when important details are missing.
  • Contacts mock venues first and lets the organizer choose where to play.
  • Invites players through simulated chat threads.
  • Waits for player and venue replies.
  • Interprets natural-language replies such as "yes but only after 21:00" or "I can bring one friend".
  • Sends reminders to players who have not replied.
  • Selects the best match format based on confirmed players and venue support.
  • Builds balanced teams from player ratings.
  • Validates the match plan for player count, budget, venue capacity, and safety.
  • Sends final confirmation messages to participating players with venue, time, format, price, assigned team, and teammates.
  • Sends a confirmation message to the selected venue.
  • Shows a full monitoring view with timeline, logs, Bedrock requests/responses, and final result.

The app is designed as a demo dashboard: the main thread represents the organizer talking with FootyAgent, while separate mock threads allow the user to answer as players and venues during the demo.

How we built it

We built FootyAgent as a lightweight full-stack application:

  • Frontend: HTML, CSS, and JavaScript.
  • Backend: Python 3.12 using the standard library HTTP server.
  • Runtime: Docker and Docker Compose.
  • AI layer: AWS Bedrock through the Strands Agents SDK.
  • Agent architecture: specialized Python agents for orchestration, players, communication, venues, team building, rules validation, and reminders.
  • AgentCore preparation: an AgentCore-shaped /ping and /invocations runtime is included for future AWS deployment.

The system is intentionally simple to run locally, but the architecture maps cleanly to AWS services.

The main agents are:

  • Orchestrator Agent: controls the workflow and decides the next step.
  • Venue Agent: contacts venues, interprets venue replies, and recommends the best option.
  • Player Agent: selects initial players and reserves.
  • Communication Agent: creates simulated messages, interprets replies, and prepares final confirmations.
  • Reminder Agent: checks pending player replies and sends reminders.
  • Team Builder Agent: balances teams based on ratings.
  • Rules Agent: validates player count, venue capacity, budget, safety, and fairness.

Team balancing uses a transparent rating-based approach. A simplified fairness objective is:

$$ \Delta = |\overline{R}{blue} - \overline{R}{red}| $$

where lower ( \Delta ) means the teams are more balanced. The app shows the final team averages and explains the balance result.

How we used AWS

AWS is central to the project in three ways.

First, Amazon Bedrock powers the language understanding layer. It is used to parse organizer goals, interpret player replies, interpret venue replies, and extract structured JSON from flexible human messages.

Second, the project is prepared for Strands Agents. The repository includes Strands-compatible tools for players, venues, team balancing, validation, and simulated communication. This allows the project to evolve from a local demo into a more production-style agent runtime.

Third, the project includes an AgentCore-shaped runtime with /ping and /invocations endpoints. This makes the app ready for deployment work using Amazon Bedrock AgentCore, ECR, and an AWS-hosted container runtime.

A future AWS architecture could include:

  • Amazon Bedrock for model inference.
  • Amazon Bedrock AgentCore for agent hosting.
  • Amazon ECR for container images.
  • AWS App Runner or ECS Fargate for the backend API.
  • Amazon DynamoDB or Aurora/PostgreSQL for persistent match state.
  • Amazon S3 and CloudFront for frontend hosting.
  • Amazon CloudWatch for logs and observability.
  • Amazon EventBridge for scheduled reminder checks.
  • Amazon SNS, Pinpoint, or external messaging integrations for real notifications.

Challenges we faced

One major challenge was making the agent workflow easy to present and explain during a live demo. A black-box chatbot would not be enough for this use case, especially in a hackathon setting where judges need to quickly understand what each agent is doing. We added a dedicated monitoring panel with timeline events, logs, Bedrock request/response visibility, and final result tracking so the demo clearly shows the system thinking, acting, waiting, and resuming step by step.

Another challenge was handling human-in-the-loop pauses. The agents cannot continue until players or venues reply, so the system needed to pause, wait for user-provided mock replies, then resume exactly where it left off. This made the demo more realistic because the organizer can role-play players and venues while the workflow continues naturally.

We also had to make the UI behave like a real messaging product. Long chat histories should not hide the input box. Polling should not erase draft messages. Rerendering should not steal focus while the user is typing. These details mattered because the presentation depends on smoothly switching between the organizer, players, venues, and monitoring views.

A final challenge was balancing realism with hackathon scope. We wanted the app to look and behave like a real coordination tool, while keeping external messages and venue bookings simulated for safety. This allowed us to demonstrate the full end-to-end workflow without sending real messages or making real bookings.

What we learned

We learned that agentic applications need more than just a model call. The hard part is the surrounding product system: state, workflow, observability, interruption handling, recovery, and human approval.

We also learned that Bedrock works well when paired with clear structured outputs. By asking the model to return compact JSON for goals and replies, the rest of the workflow can remain deterministic, testable, and explainable.

Another important lesson was that transparency improves trust. Showing logs, activity, and model requests makes the system easier to debug and easier for a user to understand.

Responsible AI considerations

FootyAgent is designed with human control and safety in mind.

  • External messages are simulated in the MVP.
  • Venue booking is simulated and should require human approval in production.
  • Injured players are excluded from confirmed lineups.
  • Team balancing is explainable.
  • The system validates budget, venue capacity, and player count before confirmation.
  • The Bedrock monitoring tab makes model interactions visible during the demo.
  • No real personal data is required; the demo uses mock players and mock venues.

What is next

The next step is to move from a local hackathon demo to a hosted AWS architecture.

Planned improvements include:

  • Deploying the AgentCore-shaped runtime on AWS.
  • Persisting match state in DynamoDB or PostgreSQL.
  • Adding real authentication for organizers.
  • Integrating calendar availability.
  • Adding real venue booking approval flows.
  • Adding WhatsApp, email, or SMS notifications after explicit human approval.
  • Supporting multiple sports and recurring groups.
  • Adding analytics for player reliability, cancellation risk, and venue quality.
  • Improving team balancing with player positions, preferred teammates, and historical performance.

Why it matters

FootyAgent is not just about football. It demonstrates a broader pattern: AI agents can coordinate real-world group activities when they combine language understanding, structured tools, workflow state, human approval, and transparent monitoring.

The football match is a familiar, concrete example. The same architecture could support community events, volunteer coordination, small business scheduling, classes, workshops, or team operations.

FootyAgent shows how AWS Bedrock and agent tools can turn a messy chat-based coordination problem into a structured, observable, and human-guided workflow.

Share this project:

Updates

Submission history