উৎস Utsa

Most people want to work on what they’re curious about. Two things usually stop them, and neither is talent: finding the right place to act, and being trusted before they have a track record. OfferNet’s real promise is solving both. Utsa is where that promise meets real people.

Utsa took shape while I was volunteering with SingularityNET. I joined the organization professionally in December 2025. If an offer can find its need, and both people can say it happened, curiosity has somewhere to go.

I defined the product scope, coordination flow, naming and visual identity. I authored the knowledge base, seed memory and agent behaviour, led the Sprint demonstration and evaluation, and developed the Telegram experience through launch specifications and engineering handoff.

The work builds on Ben Goertzel’s OfferNet research. Dhaval Khatri engineered the Sprint’s Discord API integration. I’m now working with the team to deploy Utsa on Telegram.

Early prototypes explored a dedicated contribution interface. I moved the product direction toward an agent embedded in existing community channels, reducing the extra participation the idea asked of people.

The Telegram design accepts needs and offers in ordinary language. Tags and commands are optional. Stating an interest does not automatically make someone available: uncertain signals require a private availability check before matching.

Each proposed match gives a reason grounded in what the people actually wrote. The match is a suggestion; the participants decide whether to act.

The launch design delivers matches privately. Someone who has not opened a private chat gets one discreet invitation beneath their own post, without revealing the counterpart or the match reason. Private contributions require permission before they can be shared.

An introduction is not an outcome. I designed attestation around one specific claim: what was offered to meet which need.

Both people must confirm the same outcome before the exchange counts as completed. “Not yet” leaves room for work to happen; silence is not treated as a failure by a person. Follow-up is bounded. There are no public ratings or personal scores.

Verification scales with stakes. Utsa’s stakes are low: did two people do the thing? So confirmation from both of them is enough. It is private, it needs a counterpart, and it records a completed loop rather than a judgment of quality, so there is no score to game.

Matching and attestation are designed as one service loop. Automated delivery, follow-up and bilateral attestation will be validated in the Telegram deployment before any adoption or outcome claims are made.

I separated the standing behaviour rules from the knowledge retrieved for individual conversations. The launch design covers correction, withdrawal, permission, ambiguous replies and requests to see one’s record.

Stopping participation and deleting stored information are different actions. Utsa must explain that distinction and route removal requests to the operator. It must not claim to have saved, delivered or removed something without confirmation. These are product requirements; some depend on runtime support and validation.

In June 2026, the working agent used a curated seed of real community posts to connect a new need with an earlier offer and explain the fit. Utsa was one of three awarded teams among 28 at BGI Sprint I.

That demonstrated retrieval and matching across time. It did not establish production adoption, completed-exchange rates or a deployed reputation system.

Utsa is now being deployed as an OmegaClaw-native agent on Telegram: first as its own bot, then in the BGI Commons group. The next step is validating the complete service loop: reading needs and offers in context, delivering matches privately, following up, and recording bilateral attestation when an exchange actually happens.

The main outcome measure is completed exchanges confirmed by both people. Multi-party exchange, portable reputation and cross-community coordination remain future directions.

Telegram is intake: posting a need takes seconds. A Commons portal would hold identity, browsing and the record of completed loops. These are concept screens for that second surface. The people in them are fictional.

The next interface study brings Utsa into existing community spaces. Community inbox concepts show how a relevant offer and a need can become a private suggestion.

The project questionnaire adds goals, needs, available contributions, timing, constraints, an optional public GitHub repository and sharing choices. Participants choose whether to connect, review an agreed scope and confirm a specific completed contribution.

These interactive studies use fictional people and projects. They demonstrate the proposed flow, not a working integration or enforced privacy.

One question across a year. Each time the organisation around it moved, the container changed and the function stayed.

A scoreboard flattens a person into one number on one ladder. I’m researching the opposite: reputation drawn from completed loops, like spokes of glass that stay dark until they’re relevant. Your profile stays almost hidden. When someone’s need matches what you’ve offered before, only that spoke lights, for them, at that moment.

Shared and private. The shared layer holds only attestations both people confirmed: you choose what’s visible, never what’s true. A private mirror shows your own patterns of giving, receiving and rest, visible only to you. It asks questions; it never grades.

Gratitude and seasons. Someone can acknowledge a gift even if the loop never closed. Old nodes soften rather than standing as a permanent record, so memory can hold trust without holding the worst against anyone.

Motivation, not shame. No empty spokes, no streaks, no circle to complete. A sparse mandala should read as a beginning.

This is research, not a launch feature. It grows from real attestations, starting with the first test loop.