Relay - an agent for good

• 

  case photo

• 

  view of shelter management

• 

  Agents make requests that employees can evaluate

• 

  inventory management

• 

  view agent actions

• 

  case details requested by the agents

Inspiration

Atlanta Mission is a homeless shelter near me that serves over a thousand people every night across their four locations. Over the past few years, I have helped out there in various capacities, and I have seen how complex their system is. The incredible team coordinates food and item donations, shelter capacities, dietary restrictions, counseling, healthcare, childcare, volunteers, addiction services, education and job training, and so much more. Many of these tasks depend on each other as workloads shift based on the needs of the individuals staying at the different locations, and this creates a tremendous administrative burden that makes it incredibly challenging to adapt the entire system to best serve individuals as their needs evolve.

What it does

With Strands Agents SDK, I built a system that tracks the people seeking shelter and allocates resources such as staff, donations, and volunteers between the different shelter locations as needs evolve. This demo is specific to Atlanta Mission, but it could be applied to many different shelters across the country.

The workflow begins when a new person has an intake evaluation, just like it does currently. The person seeking shelter meets with a caseworker, who now uses our platform to record their different needs. Any details that the caseworker forgets to add, the platform prompts them to fill in.

Then, the system provides informed suggestions for which shelter is best suited for this person and updates the needs of the shelter based on the people who are currently staying there.

The system tracks all of the user’s information and only presents potentially relevant information to the different people who are involved in supporting their case. For instance, details about a user’s dietary restrictions would be relevant to the staff running the kitchen, whereas details about the user's childhood would be relevant to the trauma-informed counselors, but not vice versa. This allows employees to best allocate their time by cutting irrelevant information and workload from their jobs, since they no longer need to read the entire file, while it also allows more information about each person to be saved since it is no longer an administrative burden.

When more volunteers are needed, agents suggest opening new time slots for more people to sign up and can coordinate with simulated volunteers directly if plans ever change.

When donations for certain supplies run low, the system can automatically update draft requests for resources in order to best match the needs of the shelter with the items that are donated.

The agents make suggestions for operations, but a qualified employee must approve important actions as a safeguard to prevent the agents from making mistakes that could be detrimental to this nonprofit.

When a user is ready to leave, the system updates the needs of the shelter and can coordinate follow-up caseworker meetings and prepare reminders to help ensure the continued success of the people who have stayed here.

How I built it

Relay uses a Python backend that tracks multiple cases, Atlanta Mission's four shelter programs, staff schedules, shelter capacity, support tasks, inventory, volunteer outreach, and follow-up care.

For the deployed version, requests go through a private AWS API Gateway endpoint to the backend. Strands agents run through Amazon Bedrock AgentCore and use Bedrock models with bounded, read-only tools.

The agents can identify intake needs, draft volunteer outreach, simulate volunteer responses, and propose replacement staffing when schedules change. Their outputs are only proposals: deterministic Python logic validates capacity, eligibility, staff qualifications, scheduling conflicts, permissions, and other constraints before making changes.

Relay also creates role-specific views so employees only see information relevant to their jobs. State can be stored locally in SQLite or in DynamoDB using version checks to prevent conflicting updates.

Challenges I ran into

The biggest challenge was deciding what the agents should actually be allowed to control. Since mistakes could affect people seeking shelter, I separated agent reasoning from deterministic execution. Agents can propose actions, but application logic validates them and employees retain control over important decisions.

Another challenge was providing enough context to make useful decisions without exposing unnecessary information. This led to the role-specific views used throughout Relay.

Accomplishments that I am proud of

I am especially proud that Relay is not just a chatbot. It is a stateful system where changes in one case can affect staffing, scheduling, shelter capacity, volunteers, and supplies across the workspace.

I am also proud of the safeguards that combine Strands reasoning with deterministic validation and human approval.

What I learned

I learned that agents are especially useful for problems where many changing tasks affect one another, but that does not mean they should control the entire system.

For Relay, combining agent reasoning with deterministic software and human approval was much more effective than relying on an LLM alone.

What's next for Relay - an agent for good

Next, I would connect the currently simulated volunteer, donation, and reminder workflows to real communication systems, improve resource forecasting, and add stronger auditing tools.

Long term, I would love to work directly with shelters to understand their largest administrative burdens and adapt Relay around their actual needs.

Built With

• python
• strands