We will be undergoing planned maintenance on Oct 7th 6:00AM UTC / Oct 7th 2:00AM ET

Coalition Capacity Broker

An agent that helps nonprofit coalitions share spare resources safely-automating routine matches and escalating only policy or fairness decisions that need a human.

Comment

Coalition Capacity Broker

Marketplaces help organizations find a match. Coalition Capacity Broker owns the coordination until human judgment is required.

Inspiration

Small nonprofits and community organizations often operate with two problems at the same time: they have unmet resource needs, while useful capacity elsewhere in their network sits idle.

One organization may need an accessible meeting room for an afternoon. Another may have one available. A third may have the projector that is also needed. The resources already exist, but making the arrangement happen still requires a person to remember who has what, check availability, compare policies, resolve conflicts, coordinate the handoff, and notify everyone involved.

That coordination work is repetitive, fragmented, and surprisingly judgment-heavy.

I wanted to explore a different model from the usual AI assistant or marketplace: what if an agent could quietly own that coordination loop?

Coalition Capacity Broker is built for nonprofit and community coalitions that already trust and collaborate with one another. Organizations expose pre-approved shared capacity and policies. When a need arrives in normal language, the broker determines what is possible, completes safe exchanges autonomously, and only asks a person to intervene when there is a genuine policy, ambiguity, or fairness decision.

That is the central idea behind the project:

the human should make the judgment calls; the agent should do the coordination work.

What it does

A coalition member can submit a request such as:

"We need an accessible room for about 24 people next Wednesday from 2–4 PM and a projector for a volunteer tutor workshop."

The broker then:

  1. Interprets the request into typed requirements such as resource type, capacity, time window, and accessibility.
  2. Checks live coalition state instead of guessing — available resources, reservations, organization policies, and competing requests.
  3. Rejects invalid candidates deterministically, for example a room that is too small or not wheelchair accessible.
  4. Builds feasible resource bundles across multiple organizations.
  5. Checks policy and allocation context before taking action.
  6. If every hard constraint is satisfied and the exchange is pre-authorized, it reserves the resources and completes the coordination automatically.
  7. If the remaining choice involves fairness, owner approval, ambiguity, or another decision that should belong to a person, it stops and creates one concise human decision.

The coordinator therefore does not supervise every step. They primarily see:

  • what the broker handled,
  • what resources are being shared,
  • why a particular match was safe,
  • and the small number of situations that actually need human judgment.

The product includes a Coalition Pulse, request lifecycle, decision workbench, exchange history, allocation context, resource inventory, and structured evidence trails.

A concrete example

The demo coalition contains five fictional community organizations and shared assets such as meeting rooms, projectors, laptop kits, and a PA system.

In the autonomous scenario, OpenDoor Literacy requests an accessible workshop room and projector. The broker can combine resources owned by different coalition members, verify each constraint and sharing policy, reserve the valid bundle, and record the exchange without asking the coordinator to manually broker it.

A second scenario deliberately creates a harder case: two organizations need the same scarce accessible room at the same time and both qualify under policy.

The broker does not invent a winner.

Instead, it surfaces the verified facts, recent allocation context, and available options to the coordinator. After the human chooses, the system revalidates the current state before committing the exchange.

That boundary between autonomy and judgment is the core of the project.

How I built it

I designed the system around one architectural principle:

LLM for ambiguity; deterministic code for truth.

Natural-language interpretation and soft-preference reasoning benefit from an agent. Availability, capacity, policy, fairness counters, reservations, and state transitions should not depend on an LLM remembering or inventing facts.

Agent layer

The agent is built with the Strands Agents SDK.

Rather than using a free-form chatbot loop, the project uses a reusable orchestration graph around the coordination lifecycle:

normalize → load context → match → policy gate → reserve → notify → record

with separate branches for:

  • human decisions,
  • ambiguous requests,
  • no-match outcomes,
  • and stale-state revalidation.

Strands structured outputs turn natural-language requests into validated data. Custom tools expose the deterministic matching and state operations to the agent.

The same Strands implementation is also deployed on Amazon Bedrock AgentCore Runtime, giving the project a real managed agent deployment path rather than keeping the agent only inside a local process.

Deterministic coordination core

The matching engine is written in Python and handles:

  • hard resource constraints,
  • capacity,
  • time-window overlap,
  • accessibility,
  • sharing policy,
  • existing reservations,
  • bounded multi-resource matching,
  • allocation context,
  • and commitment rules.

Before a reservation is made, the system verifies that the action is permitted. A model cannot override those rules through prompting.

This separation also makes the agent explainable: the UI can show concrete facts such as:

  • "Capacity 30 ≥ requested 24"
  • "Wheelchair access verified"
  • "Available for the full requested window"
  • "Auto-share policy enabled"
  • "Riverbend Studio rejected: accessibility mismatch"

rather than exposing model chain-of-thought.

Backend and AWS

The backend is built with Python 3.14 and FastAPI and publishes a typed OpenAPI contract.

The deployed AWS architecture uses:

  • Amazon API Gateway for the HTTP API,
  • AWS Lambda for the FastAPI application,
  • Amazon DynamoDB as transactional truth,
  • Amazon EventBridge Scheduler for background reconciliation,
  • Amazon Bedrock AgentCore Runtime as the managed Strands runtime,
  • Amazon CloudWatch for logs/operational visibility,
  • and AWS SAM for reproducible infrastructure deployment.

DynamoDB stores sessions, needs, organizations, resources, reservations, exchanges, decisions, runs, notifications, and allocation history.

The reconciliation worker periodically revisits pending work so the product is not dependent on a person reopening the app. If capacity changes and an outstanding need becomes resolvable, the broker can act in the background.

Frontend

The judge-facing application is built with Next.js, React, and TypeScript and deployed on Vercel.

Instead of a chat interface, the frontend is structured as an operational workspace:

  • Pulse shows live coalition state and recent broker activity.
  • Requests show the full lifecycle of a resource need.
  • Decisions contain only cases where human judgment is required.
  • Exchanges show completed cross-organization arrangements and their evidence trails.
  • Coalition resources and allocation history make the network itself visible.

The frontend consumes types generated from the FastAPI OpenAPI specification rather than maintaining a second manually written API model.

Every browser receives an isolated synthetic demo session, seeded with organizations, resources, historical exchanges, and a representative decision. Demo data expires automatically, so the public submission remains safe and resettable.

Challenges I faced

1. Deciding what the agent should not control

The hardest design question was not how to make the agent more autonomous. It was deciding where autonomy should stop.

Resource availability, accessibility, reservations, and organization policy are too important to leave to probabilistic reasoning. I therefore moved those into deterministic tools and made the agent reason over verified results instead of treating the model as the database.

This made the architecture slightly more involved, but it produced a much more trustworthy system.

2. Making fairness useful without pretending it is objective

When two organizations legitimately need the same scarce resource, there is no universally correct mathematical answer.

The system can provide context — priority, competing requests, recent allocation history — but it should not disguise a social judgment as an AI score.

The solution was to use allocation information as decision context, while deliberately escalating genuinely ambiguous conflicts to a human.

3. Preventing stale or duplicate commitments

Agent workflows operate over state that can change while reasoning is taking place.

A resource that was available during matching may be reserved before commitment. A decision may also be resolved after underlying conditions have changed.

The reservation path therefore revalidates current state and uses transactional/conditional persistence so a stale agent result cannot silently double-book a resource.

4. Making agentic work visible without exposing chain-of-thought

For judges and real coordinators, simply showing "AI matched this" is not enough.

I needed the application to prove what happened while avoiding raw model reasoning. The solution was a structured evidence trail: graph stages, tool actions, constraint checks, policy results, rejected alternatives, reservations, and notifications.

The user sees the facts behind the action, not hidden reasoning tokens.

5. Turning a technically working prototype into a believable product

An early interface looked more like an engineering dashboard: empty screens, technical health indicators, and little evidence of the coalition itself.

The final UX was redesigned around the way a real coordinator would work: a populated operational pulse, recognizable member organizations, resource ownership, active requests, completed exchanges, and a dedicated exception queue.

That taught me that for an agent product, showing what the agent quietly accomplished is just as important as showing the moment the model runs.

6. Supporting local development and a managed agent runtime without duplicating logic

I did not want one implementation for the application and another rewritten specifically for AgentCore.

The backend therefore keeps the coordination graph reusable. The application can execute the workflow locally, while the same Strands graph can be packaged and run on Amazon Bedrock AgentCore Runtime.

That made deployment and testing more demanding, but it kept the agent behavior consistent across environments.

What I learned

The biggest lesson from building Coalition Capacity Broker is that a useful agent is not defined by how many decisions it can make.

It is defined by whether it knows which decisions it is entitled to make.

I also learned that combining agent reasoning with conventional software engineering produces a stronger system than trying to replace deterministic logic with an LLM. Structured outputs, typed APIs, transactional storage, policy checks, and tests are not separate from the agent experience — they are what make meaningful autonomy possible.

Finally, I learned to think about agents less as conversational interfaces and more as background operational actors. The most valuable moment in this project is often not when the application answers a question. It is when nothing needs to be asked at all: a valid resource exchange has already been coordinated, while the one case that truly requires a person's judgment is waiting clearly and safely in the decision queue.

What I'm proud of

Coalition Capacity Broker is not a simulated chat wrapper around an LLM.

It is an end-to-end agentic application with:

  • a real Strands orchestration graph,
  • deterministic resource and policy tools,
  • managed AgentCore deployment,
  • transactional cloud state,
  • scheduled background reconciliation,
  • human-in-the-loop escalation,
  • structured evidence trails,
  • a public product UI,
  • and reproducible evaluation focused on preventing unsafe autonomous commitments.

Most importantly, it demonstrates the product behavior I wanted from the beginning:

routine coordination disappears into the background; human attention is reserved for human decisions.

Built With

Share this project:

Updates

Submission history