উৎস Utsa
A coordination agent that matches people by what they need and what they offer, and remembers across time. One offer, one need, one verified match at a time. First place in its track at the inaugural BGI Sprint.
Interactive 8-screen UX prototype · matching and notification flow
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.
Utsa began with a question I had been carrying for years: how do people find meaningful ways to contribute without relying on luck, familiarity, or institutional proximity?
My training as an architectural designer shaped the way I approached this work. I was less interested in building another platform and more interested in understanding how people move through trust, proximity, and exchange. Spatial thinking became coordination thinking: where friction appears, what remains hidden, and what allows a system to feel inhabitable.
My role was translating coordination theory into product logic: how a person enters, how trust begins, how a loop closes, and how reputation becomes legible without adding friction too early. The coordination model builds on Ben Goertzel’s OfferNet vision.
"Not a platform. A plugin. The function travels. The container changes."Utsa product framing
A civic question before it became an AI coordination question.
A much earlier version of the same question appeared in Vancouver through Van Volunteers, a volunteer-matching concept I documented years earlier while exploring civic participation, profile logic, and community access.
The form changed, but the underlying question stayed the same: how do you help purpose find the right place to act?
The system stayed intentionally narrow: offer, need, match, attest.
What do you bring?
A person offers time, skill, compute, care, or a resource.
What is missing?
A person, project, or working group states the need clearly.
Find the connection.
The system suggests a possible exchange without turning it into a social feed.
Close the loop.
Both parties confirm the exchange. That confirmation becomes the first trust signal.
Capability first. Biography second.
One design question I introduced early was whether contribution could appear before identity.
The Persona Curtain explored a softer entry point: capability first, biography second. A person could be known by fulfilled exchanges before choosing how much of themselves to reveal.
The goal was not anonymity. It was to create a brief threshold where contribution could speak before assumption took over.
Intent
Skill
Contribution
Attestation
Name
Image
Location
Biography
An early interface made the coordination model tangible.
The eight-screen study translates the coordination model into a navigable flow: pledge, offer, need, matching, attestation, reputation, and network pulse.
It records an earlier interface direction, before Utsa moved toward lower-friction deployment inside the channels where communities already work. It is shown as evidence of the product and interaction thinking, not as the current implementation.
Open interaction studyRetention was not a feature problem. It was a location problem.
The first live pilot made one thing clear: people pledged through a dedicated interface during the summit, but contribution only became durable when the loop moved into spaces where the community already worked.
The stronger direction was to place the same matching logic inside existing channels, as a lightweight embedded bot model.
Same loop. Less friction. More social density.
I wrote the full bot specification for Mattermost. It has not shipped there yet, and it stays a surface I intend her for. The real testbed was the community channel where I ran the matching by hand. The durable work was the matching function itself: offer, need, match, attest.
Simple matches first. More complex coordination only works after trust has data.
Offer → Need → Match → Attest
One repeatable loop. A contribution happens, both parties confirm it, and that record becomes the seed for trust.
The first layer is not the whole product. It is the data foundation.
Multi-party loops
A needs what B has. B needs what C has. The system can begin to surface transitive chains when enough activity exists.
Complexity waits until the network has density.
Trust from completed exchange
Reputation emerges from attestation history, not self-description.
The signal becomes harder to fake because it is downstream of completed work.
Any community. Any surface.
The same matching logic can move between channels, tools, and communities.
The function travels. The container changes.
Presented on the main stage during the first day of BGI Summit 2025 in Istanbul.
The talk introduced Utsa publicly through one simple idea: contribution should be easier to find.
It framed Utsa as a way to connect purpose, trust, and collective intelligence without making another heavy platform.
Persistent memory. Portable coordination.
Utsa is being built on OmegaClaw’s persistent memory. The agent can retain offers and needs across time, retrieve relevant earlier context, and surface a match when the right counterpart appears later.
The interface is not the system. The same coordination function can operate inside Discord, Telegram, Mattermost, or another community surface while preserving the continuity required for matching.
Attestation and portable reputation remain the next layer of the product architecture. The function travels. The container changes. The memory persists.
From coordination theory to a working agent, and a first-place win.
At the inaugural BGI Sprint, a three-day build in the SingularityNET ecosystem, Utsa became a live agent. I owned product, design, evaluation, and the demo, and authored her knowledge base and seed memory: the agent’s role, voice, and reasoning rules. My teammate Dhaval Khatri engineered the Discord API integration. Because she runs on OmegaClaw’s persistent memory, Utsa remembers across time: post a need today, and when the right offer shows up weeks later, she connects you.
The proof was recursive. Before any agent existed, I ran the matching by hand in a community channel, and real teams formed, including my own. I built Utsa using Utsa, and the sprint’s official page pointed participants to that channel to find teammates.
In the live demo I posted a need, and Utsa reached back to an offer posted weeks earlier, explained why it fit, and connected us. Two people, posting at different times, connected by an agent that remembered.
Utsa won first place in its track, one of three awarded teams from twenty-eight, and presented at the finals showcase. The event itself carried the visual identity I designed, so Utsa and the Sprint share one design language.
Utsa / OfferNet · Track 3 winner
Not a bot to command. A co-creator in your corner.
Utsa was built and demonstrated on Telegram, with a Discord API integration bridging the LFG channel where the community already posts. Deployment into BGI Commons on Telegram, formerly BGI Nexus, is the current work. Attestation arrives with her own instance, which is also what turns seeded memory into continuous persistence. From there the matching loop carries into every channel where communities already live. The design intent is character, not chrome: less a bot you operate, more a co-creator that knows what you bring.
Think of the best recruiter you ever had, the one who actually read your file and only called when something real appeared. Utsabot holds your offers, remembers your attestations, and speaks up when a need matches what you carry. It works for the match, not for the feed.
The work continues as the ecosystem shifts form.
Utsa now exists as a working, open-source agent, and the ideas keep evolving through conversations connected to BGI and the wider SingularityNET ecosystem.
Ongoing product conversations with Ben Goertzel and the BGI team continue to inform how the backend architecture may evolve as agent ecosystems mature.
Some projects continue as products. Others remain valuable because they clarify what kind of system is actually needed.