• 

  message example 1

• 

  message example 2

• 

  message example 3

• 

  what my agent booked

Inspiration

2 days ago, I met a marketer who is redefining real world serendipity. She's been exploring this for the past 2 years and I've never seen anyone so passionate about human connection. But she cannot code, she cannot turn her vision into a reality.

Coincidentally, I've been building Oro for the past 3 month. Oro is an AI fashion stylist you can text through iMessage. With a team of 3 incredible engineers and fashion lovers, creating an agent at production skill with custom tools took 3 months. Getting a number, provisioning, connecting credentials, and managing workflows reliably took an insane amount of engineering before anyone could even have a conversation.

Oro now answers to 50 beta users every morning. But this was only possible because we know code.

Hypha exists because human creativity should not be limited by technical ability.

What it does

Hypha is an agent you text (or speak to) to build other sharable agents.

Similar to an OpenClaw/GrokBot/Muse, Hypha is a centralized orchestration layer. The reason for their wide consumer adoption is because of how easy it is for a non-technical person to understand how to use it. It's by genius design that sub-agents and multi-step plans are almost fully abstracted away from the user's view.

Through iMessage, users describe what they want to create through text or voice memoes. Hypha creates specialized RAG agents called Sprouts, with their own persisted instructions, knowledge, and tools. Sprouts contain notes, scope-specific context files that the user -- or Hypha -- can add, edit, and import.

Tools, such as event booking, can be programmatically given to Sprouts by Hypha. Integrations do not use API keys, they are authenticated through 1-click deep-links.

On creation, Sprouts are asssigned a sharing code and link. Anyone can follow the link, or text their Hypha with the code, to access another user's Sprout. Deployment is automatic.

For hackUTD, this could mean turning the attendee handbook into a help bot you can text. For a small business, it could look like automating booking requests or closing thousands in sales without a human. And for myself, it would look like changing the future of fashion :)

I believe the people who do the work should be able to build the tools for it, and share it with the world.

How we built it

Hypha is built around three core technologies:

1. Photon iMessage
2. NVIDIA Nemotron and Brev for inference
3. SpacetimeDB for state persistence

The backend runs on Python/FastAPI with Haystack (RAG system).

How I built it

I built Hypha with Python and FastAPI, coordinating messaging, model inference, and persistent state so users can create personalized assistants called Sprouts through iMessage.

Photon

I used Photon as the messaging layer between iMessage and my backend. Incoming texts arrive through signed webhooks, which I authenticate and deduplicate before routing them to either Hypha’s builder or the user’s selected Sprout. I retain the conversation and agent identifiers so replies return to the correct thread and sender.

For onboarding, I use Photon’s participant assignments to connect users to an iMessage destination. Shared Sprout links reuse existing assignments or create one after the recipient explicitly connects.

Outgoing replies enter a persistent, encrypted outbox before submission. I track Photon’s message IDs and delivery states, reconcile uncertain outcomes, and preserve ordering for replies containing multiple text bubbles. Photon also supplies voice-note attachments, which I download through authenticated requests before transcription.

NVIDIA Nemotron

I self-hosted NVIDIA Nemotron 3.5 Lightning 30B through vLLM on Brev to power Hypha’s conversational builder. The model receives conversation context and function schemas for actions such as creating a Sprout, selecting one, and updating its instructions.

Nemotron proposes structured tool calls; my backend validates their arguments, checks ownership, and executes authorized operations. I persist each tool’s intent and result, then return the result to Nemotron so its confirmation reflects what actually succeeded.

For knowledge retrieval, I implemented a separate Nemotron-3-Embed-1B service. Markdown notes are split into heading-aware passages, embedded, and stored with their source versions. Questions are embedded using the same model, and Python selects the five closest passages by cosine similarity. OpenAI’s gpt-5.6-luna uses that context to generate the answer. The embedding deployment still needs live verification.

I also use Nemotron Speech 0.6B through NVIDIA NeMo to transcribe voice notes, allowing spoken requests to enter the same workflow as text.

SpacetimeDB

I used SpacetimeDB as the persistent store for both user data and execution state: Sprouts, instructions, notes, embeddings, conversations, Photon assignments, background jobs, tool results, and outgoing replies.

A private TypeScript database module accepts requests only from my configured backend identity. The browser communicates with FastAPI, which applies user-level authorization before accessing or modifying data.

The hackathon implementation uses a revisioned application snapshot. Each commit must match the revision originally read; conflicting operations reload and recompute their changes. The database also validates invariants such as immutable ownership, note-version progression, and storage limits.

Persisted worker claims and tool results support recovery after interruptions. Source-version checks prevent an old indexing job from replacing newer notes and stop queued answers from being delivered after their sources change.

Challenges I ran into

A product is either complex for the user or complex for the engineer. Hypha attempts to condense setup that would take months of engineering into 2 minutes and a few text messages. From a design perspective, I had to make that abstraction intuitive. From an engineering perspective, I had to make that simplicity dependable.

The first challenge was turning conversation into reliable actions. A model can request a change, but my backend must establish permission, execute it, and preserve enough state to avoid repeating it after a retry.

The second was handling asynchronous messaging. A submitted reply may remain undelivered, and a timeout may leave its status uncertain. I built persistent delivery tracking and reconciliation so the application could handle those outcomes without blindly resending.

The third was keeping context current. Users can edit notes or switch Sprouts while background work is running. Revision checks, source versions, and routing checks prevent older work from overwriting changes or reaching the wrong conversation context.

Finally, I had to decide which complexity users should see. I kept creation and configuration inside iMessage, while giving longer notes a mobile editor. That preserves a conversational entry point without forcing substantial knowledge editing into a text thread.

Accomplishments that I'm proud of

I’m most proud of building something I can demo live from both sides: a creator building and configuring a Sprout, and another person interacting with it through iMessage.

I built Hypha solo while learning Photon, SpacetimeDB, and NVIDIA Nemotron for the first time. Getting those technologies to work together in a usable product was a huge accomplishment for me.

I’m also proud of implementing the RAG pipeline: splitting notes into meaningful chunks, generating embeddings, retrieving relevant passages, and using them to ground answers in the creator’s knowledge.

What I learned

Building Oro taught me how much work surrounds building an agent. Building Hypha taught me how much of that work a creator should never have to think about.

A powerful model is one ingredient. Accessibility also depends on whether someone can supply their knowledge, change their agent’s behavior, and make it useful to another person.

That changed how we approached the product: every technical decision had to support a simpler experience for the creator.

What’s next for Hypha

I want to evolve Hypha from an assistant builder with predefined tools into an autonomous system that can build the tools a user needs.

Each Hypha would have its own isolated computer and VM, where it could write code, install dependencies, test integrations, deploy services, and create API endpoints. A request could become a working tool that Hypha builds, connects to a Sprout, and maintains—all initiated through iMessage.

The hardest next step is earning enough trust for that autonomy. I want Hypha to verify its work, manage credentials securely, operate within clear permissions, and recover from failures. That foundation would let it take responsibility for the full path from a user’s idea to a running service.

Built With

• brev
• chatgpt-5.6-luna
• docker
• haystack
• nemotron-3-embed-1b
• nemotron-3.5-lightning
• nemotron-speech-streaming-en
• nginx
• ngrok
• photon
• python
• spacetimedb
• typescript