A human-facing coordination layer translating OfferNet theory into product logic. One offer, one need, one verified match at a time.
Utsa is a coordination layer for matching the right people with the right projects. It opens with HyperSprint as a Looking-for-Group Discord channel, then grows into a matching agent over time.
Utsho — the source, radiating outward.
Utsho means source in Bangla. The name holds the central design question. How contribution begins, how trust forms, and how a loop closes before reputation exists.
The roadmap
How it grows
Utsho — the source, radiating outward.
Stage 1 · Now
A channel.
Utsa begins as a Looking-for-Group space on Discord, opening with HyperSprint. People post what they need and what they offer. No AI yet, no profiles. Just a clear way to find each other across cohorts, time zones, and disciplines.
#need#offer#team#pledge#direction
Stage 2 · Soon
UtsaBot.
A light agent joins the channel. It welcomes people, helps them shape their post, and surfaces possible matches.
Stage 3 · Next
Connected.
UtsaBot reads, with permission, from the profiles and skills people already maintain elsewhere. The matching gets richer without anyone having to fill in another form.
Stage 4 · Ahead
A full matching agent.
Utsa grows into an agent that watches the whole weave. Proposing teams to people, and people to teams.
Attestation
When a loop closes, both sides confirm it. Utsa doesn't hold the record. It emits the attestation and reads it back, so reputation grows from what people have actually done, not what they claim. The record lives where the profile lives. This is the layer the community can build on, and the one a coordinator can call when it needs to know who has shown up.
The design
Utsa is stateless
Utsa doesn't hold a profile of you. It carries no data of its own.
What makes Utsa recognizable as Utsa isn't a logo or an app. It's the offer itself. The way it listens. The match that finds you when you weren't looking.
The brand is the offer. The offer is the brand.
The container may change. The offer stays the same.
Where you come in
Issues & hackathon options
Utsa is a matching layer, not an identity system. People post what they offer and need, and Utsa helps the right two find each other, with permission.
Profile-agnostic · consent-first
Technical
1
Memory
Matching is manual right now. Someone posts a need and only connects if a human remembers a matching offer. Utsa needs to remember offers and needs from before and surface the relevant ones automatically. The same memory-surfacing problem as OmegaClaw, an ECAN-like stand-in until ECAN.
2
Goal creation
Utsa needs to turn a vague goal, "I want to get into agent coordination," into something concrete and matchable. A team, a role, a project.
3
Community instantiations
Utsa should deploy to any community from a template and plug into whatever profile source they already use, Deep now, its successor, LinkedIn, with no change to the matching core.
4
The bot itself
Build the first working UtsaBot in the sandbox channel. It reads tagged offer and need posts, stores them, surfaces matching earlier posts, and replies with an intro. The lightest viable bot path, hosting plus storage, is the real dependency.
Non-technical
1
Hand-matching in the channel
Spot when an offer and a need line up and make the intro. Keeps it alive now and shows the bot what good matches look like.
2
Writing prompts & post format
Craft the offer and need template, and the bot's messages, so they feel warm and clear, not robotic.
3
Labelling good vs. bad matches
Mark which offer and need pairs are real matches. This set is what we test any solution against.
4
Goal-shaping conversations
Help vague people get specific. Join a team or start one? What role? Surfaces the questions the bot should ask.
5
Consent & safety wording
Opt-in and opt-out language, and what "utsa is listening" means in plain terms.
6
Setup guide / runbook
Document how to set up Utsa for your community, step by step.
7
Testing as a real user
Use it, try to find a team, and report what felt confusing.
