Hatcommways

From - someone should to we did.

Comment

Vision

Our vision is to make community action easier to start, easier to join, and easier to sustain — so people can contribute alongside everyday life, while Hatcommways coordinates the complexity behind the scenes and maps make people, roles, support, and collective progress visible..

Inspiration

I live in an IT-focused area where many people care about animal welfare, the environment, neighborhood improvement, and cultural activities. The willingness to contribute is there, but turning that willingness into action is still difficult.

That made me ask:

Why is willingness to contribute so common, while coordinated community action is still so difficult?

I found five connected gaps:

  • Discovery gap — people often do not know what community activities are happening around them, especially smaller non-commercial events.
  • Fit gap — even when they find an event, they may not know where they fit, what role they can take, or how much time is needed.
  • Coordination gap — organizers spend too much effort managing people, schedules, dependencies, resources, and changes instead of focusing on the purpose of the event.
  • Visibility gap — participation is not visible enough to motivate others or show how a community is coming together across areas, roles, organizations, and professions.
  • Memory gap — what one event learns is usually lost, so the next event often starts again from almost zero.

These are not separate problems. They are parts of the same missing coordination layer.

I wanted to build something that could carry this coordination around people, preserve useful intelligence across events, and help communities move more easily from intention to action —

from “someone should” to “we did.”

What it does

Hatcommways turns a community goal into coordinated action by connecting organizers, participants, sponsors, and local people through one shared execution system.

Unlike conventional event, volunteer, or community apps that mainly help people discover or register for activities, Hatcommways coordinates the full journey from goal definition and work design to participation, resource support, real-world execution, blocker handling, selective replanning, and governed decision-making.

Organize the Work

Turn a community goal into stages, work items, dependencies, timelines, meetings, and actor requirements. AI agents help design and coordinate the work, identify participation or resource gaps, manage sponsors and support, track execution updates, and selectively replan only the affected work. Organizers remain in control of consequential changes and keep a reusable history of outcomes and lessons.

Govern Consequential Decisions

Hatcommways keeps human authority at the center of execution. Organizers can review and approve consequential replans, control sponsor commitments, delegate responsibilities, manage plan versions, and keep important decisions auditable. Agents can reason and propose changes, but they do not directly rewrite authoritative project state.

Participate with Clear Responsibility

Discover events where you can meaningfully contribute, choose roles based on interests, skills, and availability, and manage approved work, meetings, schedules, and updates from one dashboard. Participants can naturally report changes such as delays, missing resources, access problems, or completed work without needing to understand the entire project structure.

Support Specific Needs

See what an event actually needs — funding, materials, equipment, venues, transport, services, or other support — and contribute directly to a specific requirement. Sponsors and supporters can help through external payment or service links while remaining visible as contributors where appropriate.

Discover and Join Community Action

Explore nearby public activities by location, category, map, role, organization, or community. People can watch an event before joining, understand where action is already happening, see where help is still needed, and move naturally from observer to participant, supporter, or organizer.

How we built it

We started by breaking the community-action problem into the gaps that repeatedly prevent people from moving from intention to execution: discovery, planning, participation fit, responsibility allocation, resources and sponsorship, coordination, real-world blockers, replanning, visibility, governance, and organizational memory.

Instead of building one large AI assistant, we decomposed these gaps into a bounded multi-agent system with 25 specialized agents. Hatcommways uses specialized roles for event planning, work design, actor requirements, participation guidance, human-update interpretation, blocker assessment, coordination, selective replanning, support matching, acceleration, and outcome/blueprint learning.

Each agent receives only the context required for its responsibility rather than unrestricted access to the entire project.

Two-layer architecture

The deterministic layer owns authoritative truth:

  • users, roles, and permissions
  • event membership
  • work graphs and dependencies
  • participation and meetings
  • resources and sponsorship commitments
  • blocker state
  • plan versions
  • approvals and governance decisions
  • idempotency, retries, and validation

The agentic layer, built with Strands Agents, handles work that benefits from contextual reasoning:

  • turning a community goal into an executable structure
  • designing work and actor requirements
  • interpreting participant updates
  • deciding whether a real-world change creates a blocker
  • coordinating alternatives
  • selectively replanning affected work
  • identifying resource and support gaps
  • learning reusable outcomes and blueprints

Agents do not directly rewrite authoritative project state. They produce typed proposals, which deterministic services validate against current state, permissions, dependencies, and approvals before anything consequential is applied.

Human-led governance

Governance remains human-led. Hatcommways can surface risks, missing approvals, policy conflicts, authority boundaries, and decision points, but agents do not become the governing authority.

Organizers and responsible organizations retain control over consequential plan changes, sponsor commitments, delegated responsibilities, and other governed decisions. The system records approvals, plan versions, evidence, and decision context so important changes remain auditable and traceable.

This creates a clear boundary:

Agents can reason about governance conditions and surface decisions, but authority remains with people and organizations.

Participation and visibility

Hatcommways is designed around continuous participation and motivation, not only planning.

Google Maps supports public event discovery and inside-event operational context, helping people see where events, participants, resources, sponsors, meeting points, and support are active.

The map therefore does more than provide navigation — it makes collective action visible.

AWS event-driven execution

PostgreSQL remains the source of truth, while committed domain events flow through:

Amazon EventBridge → Amazon SQS → ECS/Fargate workers → bounded Strands workflows

Amazon SQS provides asynchronous delivery and bounded retries, while exhausted failures move to a Dead-Letter Queue (DLQ) instead of disappearing or retrying indefinitely.

The agents use Amazon Nova through Amazon Bedrock for reasoning. Runtime events carry message, correlation, and causation identifiers, while persisted run records and idempotent claims prevent duplicate delivery from producing duplicate agent work or side effects.

Observability

For production visibility, we integrated:

  • CloudWatch Transaction Search
  • AWS X-Ray spans
  • structured runtime logs
  • persisted agent-run records

A single execution can be traced across:

PostgreSQL → EventBridge → SQS → ECS → Strands → Amazon Bedrock → tools → typed proposal or failure outcome

This gave us a hybrid architecture where:

Agents reason and propose, deterministic services validate and apply, governance keeps authority with people, maps make participation visible, and AWS keeps execution reliable.

That combination allows Hatcommways to adapt to real-world community execution without turning coordination or governance into uncontrolled autonomous decision-making.

Challenges we ran into

One of the hardest problems was keeping agent output grounded to the exact event context. During coordination, an agent once referenced an unrelated actor because multiple UUIDs were present in the prompt. We fixed this with explicit eligible-actor lists and strict deterministic validation.

Another challenge was distinguishing normal execution changes from real blockers. A late participant does not always require replanning, so the system had to consider role importance, work windows, dependencies, access, participation, and timing flexibility before escalating.

We also had to make selective replanning truly selective. Instead of regenerating the whole event, an affected-work resolver updates only directly impacted work and downstream dependencies while freezing unrelated stages and assignments.

Keeping organizer and participant views consistent was another issue. An approved replan initially updated the event plan but left stale timing on the actor dashboard, so we made actor-facing timing and messages update transactionally.

The AWS runtime introduced distributed-systems challenges too. SQS can redeliver messages, so we added execution identity, idempotent claims, PostgreSQL run records, bounded retries, and a DLQ to prevent duplicate work and preserve failures.

Observability was essential because one run can cross PostgreSQL, EventBridge, SQS, ECS, Strands, Bedrock, and tools. Correlation IDs, run IDs, CloudWatch Transaction Search, and X-Ray let us trace executions end to end.

Deployment also brought practical problems. When the local Docker daemon was unavailable, we used temporary AWS CodeBuild to build and push the production image to ECR, then removed the temporary infrastructure.

Finally, maps required more than placing markers. We separated public event discovery from inside-event operational context while preserving privacy and still making people, resources, and support visible.

Agent reasoning became reliable only when grounding, persisted state, deterministic validation, failure handling, and observability were designed around it.

Accomplishments that we're proud of

We are proud that Hatcommways became more than a planning prototype — it grew into a working community-execution system that connects discovery, participation, coordination, sponsorship, real-world updates, selective replanning, and outcomes in one product.

On the product side, we built a complete journey for organizers, participants, sponsors, and the wider community. Organizers can turn a goal into structured work, participants can join based on role and availability, sponsors can support specific needs, and communities can discover activity through maps and live event context.

We are especially proud of the execution loop. A participant can report a real-world change, and Hatcommways can interpret it, determine whether it creates a real blocker, identify only the affected work, coordinate alternatives, selectively replan when necessary, and return consequential changes to the organizer for approval. Unrelated work remains untouched.

On the technical side, the stack is deliberately separated by responsibility:

  • Strands Agents + Amazon Bedrock/Nova handle bounded reasoning and typed proposals.
  • PostgreSQL remains the authoritative source of truth.
  • Amazon EventBridge + Amazon SQS provide reliable asynchronous event delivery, retries, and workload isolation.
  • DLQ handling preserves exhausted failures instead of losing them.
  • ECS/Fargate runs the production API and long-lived runtime worker.
  • Idempotent execution prevents duplicate SQS delivery from producing duplicate agent work or side effects.
  • CloudWatch Transaction Search, X-Ray, structured logs, and persisted run records provide end-to-end observability across the runtime.

We also verified important production behaviors rather than only designing for them: duplicate delivery resolves to the same persisted run, retries are bounded, failed work reaches the DLQ, and one execution can be traced across PostgreSQL → EventBridge → SQS → ECS → Strands → Bedrock → tools → typed output.

Google Maps also became more than a location feature. It supports event discovery, operational context, resources, sponsors, and participation visibility, helping make collective action visible throughout the product.

Most importantly, the final architecture matches the problem we wanted to solve:

People make commitments, agents help coordinate complexity, deterministic services protect the state, AWS keeps execution reliable, and humans remain in control of consequential decisions.

What we learned

The biggest lesson was that real-world coordination is not mainly a planning problem. Plans change as people, access, resources, timing, and dependencies change, so the system has to remain useful after execution begins.

We learned that agent quality depends heavily on context boundaries. Giving an agent more information is not always better; giving it the exact actors, work, dependencies, and resources it is allowed to reason about produces safer and more reliable behavior.

We also learned that replanning should be selective rather than global. A disruption in one part of an event should not cause unrelated work, people, or stages to change.

Building the production runtime showed us that agent systems also need ordinary distributed-systems discipline: idempotency, retries, failure isolation, persistent execution identity, and observability matter just as much as model reasoning.

Finally, we learned that community action becomes stronger when participation is visible. Maps, roles, responsibilities, resources, and support make it easier for people to see that others are already contributing and to understand where they can join.

What's next for Hatcommways

The next major step is to strengthen human-led governance.

Hatcommways will allow communities and organizations to define how decisions should be made: who has authority, what requires approval, how responsibilities can be delegated, what evidence is needed, and how exceptions or conflicts should be handled. Agents can monitor execution against these rules and surface issues, but final governance authority remains with people and organizations.

We also want to build a Hatcommways Memory Map that preserves useful knowledge across events — successful work structures, recurring bottlenecks, effective coordination patterns, sponsor and resource strategies, governance decisions, failures, and reusable event blueprints.

The goal is not simply to remember past events, but to make that knowledge applicable to future ones, so communities do not have to start from zero every time.

Over time, we also want to deepen:

  • sponsor coordination
  • reusable event templates
  • cross-community collaboration
  • outcome tracking

while keeping the same core principle:

Human governance defines the rules, agents help coordinate within them, and shared memory helps each new community action start stronger than the last.

Built With

Share this project:

Updates

Submission history