DEV Community: sirmos

Manrova: What We Learned Building a Multi Agent System That Watches, Doesn't Just Answers

sirmos — Sun, 30 Aug 2026 18:35:47 +0000

This post was created for the purpose of entering the All Things Agentic Hackathon.

The question that started it

Most agent demos answer a question you already knew to ask. Manrova started from a different question: what if the hard part isn't answering, it's noticing?

A vessel produces a constant stream of operational signals: GPS and radar position, crew watch schedules, near-miss reports, compliance records. None of that is missing information. The problem is that nobody has time to correlate four different systems, for every vessel, every day, before a small disagreement becomes an incident report instead of a warning.

So instead of building a chatbot that waits to be asked, we built a system of agents whose job is to watch continuously, investigate when something looks off, coordinate with each other, and only interrupt a human when a decision genuinely needs one.

The shape of the system

Manrova has four specialist agents and one orchestrator, the Officer of the Watch (OOW).

A Navigation Integrity Agent checks whether GPS and radar-derived position actually agree.
A Crew Readiness Agent looks at rest and duty patterns for fatigue risk.
A Fleet Pattern Agent scans near-miss history across the whole fleet, not just one vessel.
A Compliance Readiness Agent reasons about certificate exposure relative to a vessel's actual schedule, not just a raw expiry date.

None of them work in isolation. When the Navigation Integrity Agent flags something, the Officer of the Watch decides what other context is worth pulling in, correlates the evidence, and runs it through deterministic risk logic to settle on an overall severity. Below a threshold, Manrova keeps watching, silently. Above it, the OOW prepares a response and stops, waiting for a human to approve anything that goes out externally.

That gate was the single most important design decision in the whole project: the system assists the watch. It does not replace the watch.

The design choice we'd defend the hardest

Safety-critical math never touches a language model. Position deviation, weighted risk scoring, incident state transitions: all deterministic Python, computed the same way every time, auditable, reproducible. The LLM layer sits on top of that structured output, interpreting it and narrating it in plain language for a fleet operator.

It would have been faster to just hand raw telemetry to a model and ask it to decide. It also would have been the wrong call for a system where a false negative has real consequences. Deterministic logic draws the boundary. The agents interpret what's inside it. A human holds final authority when the boundary is crossed.

Building the enterprise trust layer for real

For the Fortified Enterprise Fleet track, we didn't want to just describe these components conceptually, we wanted them actually running.

Agent Registry: all five agents (four specialists plus the OOW) are published to a live Firestore collection, versioned, with the exact permissions each one is allowed to exercise.
Agent Gateway: every specialist call is routed through a policy check against that registry before it's allowed through.
Model Armor (our own guardrail implementation of the same pattern): any untrusted free text, like a near-miss report description, is screened for prompt injection and has PII redacted before it ever reaches a model.
Agent Observability: every investigation is wrapped in OpenTelemetry trace spans, so the full reasoning chain is inspectable.
Memory Bank: completed investigations persist in Firestore, so a vessel's history survives across sessions instead of resetting on every request.
Agent Identity: each agent runs under its own IAM service account, least-privilege, rather than one shared credential doing everything.

Real data, not just demo data

It bothered us that most hackathon demos run on the same three lines of fixture data forever. Manrova's live site supports two paths: a one-click fixed demo scenario, and a real registration flow where any fleet operator can register, add a vessel (a real name or an internal alias, never required to disclose a hull identity), and run an investigation on genuinely entered navigation and crew data. For testing, we used public AIS-derived position data for a real, currently operating vessel as the basis for a realistic scenario, clearly separated from the synthetic demo data used elsewhere in the app.

What surprised us

We expected the hard part to be prompt engineering. It wasn't. The hard part was deciding, agent by agent, exactly what each one was allowed to trust, when it should hand off to another agent, and where control had to return to a human no matter what the model said. Getting that division of responsibility right mattered more than any single prompt.

We also came away convinced that deterministic logic and agentic reasoning aren't competitors. They're better together than either one trying to do the whole job: the deterministic layer sets the boundary, the agents interpret what's happening inside it, and a human holds the final call when the situation actually calls for one.

Try it

Live site: manrova.vercel.app
Source: github.com/serinalapoez/Manrova

Built with Gemini (3.5+) via Google's Agent Development Kit, with Firestore as the persistence layer, and a parallel implementation on AWS Strands Agents SDK running on Amazon Bedrock.

Three fields, three different errors, and the bug wasn't mine

sirmos — Wed, 12 Aug 2026 07:31:11 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The setup

Brickwarden has two agents.
One builds a tokenized asset on Ethereum Sepolia.
The other watches it and can freeze or burn tokens on its own if something looks wrong. Every other piece worked, tokenize, launch, whitelist, mint, all three of Warden's compliance triggers.
The last piece was dividends, and it turned into a two week standoff with one API call.

The bug that wasn't a bug

Paying out dividends meant approving a stablecoin allowance first, so the contract could pull funds from the wallet.
The docs gave a clean example payload. I matched it exactly.

It came back with:
"messages": "Tokenizer address is required if token symbol is one of BKN/USDT/USDC"

Fine, add the field. Retried.

"messages": "User not found"

Same wallet. Same address that had signed every other successful call in the project, tokenize, whitelist, mint, all proven on chain.
Tried the field as an email instead of an address. Different error.
Tried both fields together. A third, completely different error:
"messages": "client-signed prepare must return exactly one txId"

Three fields, three combinations, three unrelated failures.
At that point it stopped looking like something I was getting wrong and started looking like something broken on the other end.

Ruling myself out

Before saying that to anyone, I wanted to be sure.
I pulled the token's real spender address straight from Brickken's own get-tokenizer-info endpoint instead of guessing it. I matched their documented example field for field. Same wallet, same escrow address, same shape as their own docs.
Still "User not found."

That was the point I wrote up the exact payload and the three error messages and sent it to Brickken's support, instead of trying a fourth combination and hoping.

The resolution

A few days later, Davide and the Brickken team confirmed it: a backend bug in the approve flow for shared payment tokens, fixed and deployed to sandbox. Same code, same payload I had already tried and matched to their docs, ran clean the moment their fix landed.

Approve result:
{
"success": true,
...
}

Dividend distribution went through right after.

What stuck with me

The instinct when an API call fails three different ways is to assume you are missing something, and usually you are. But when the exact same wallet, the exact same shape, matching the vendor's own example, produces three unrelated errors across three attempts, that pattern itself is a signal worth trusting. Chasing a fourth field name would have wasted more time than writing up what actually happened and asking.

Sometimes the fix is not in your code at all, and knowing when to stop debugging and start asking is its own skill.

Repo: https://github.com/sirmos/Brickwarden

Thank you for reading!!!

A one line array check that was hiding a bigger bug

sirmos — Wed, 12 Aug 2026 07:15:19 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

Brickwarden pairs two agents around one tokenized asset on Ethereum Sepolia, built on Brickken's sandbox API. An Issuer Agent creates the asset, runs the offering, whitelists investors, mints tokens, and pays out dividends. A Warden Agent watches the same asset for compliance triggers and can revoke access or burn tokens on its own the moment something goes wrong, no approval needed from the Issuer.

Every write action either agent takes, mint, whitelist, burn, approve, goes through one shared helper function that prepares a transaction, signs it locally, and sends it to the chain.

Bug Fix or Performance Improvement

That shared helper assumed the API always returns an array of transactions to sign. That held up for months, until one specific call broke it.

I needed to mint tokens to an investor who was already whitelisted, so I passed needWhitelist: true anyway, expecting it to just get skipped. Instead the API responded with transactions as a single object instead of an array, and the loop that signs each transaction crashed with:
Re-mint failed: prepared.transactions is not iterable

![Terminal showing the crash after two earlier failed attempts, ending in "prepared.transactions is not iterable"]

Nothing in the error pointed at the real cause. I compared the raw response against a normal, working mint call side by side, and the only difference was that one field's shape, an object where an array should have been, and only when that one flag combination fired.

Code

Before:

console.log(`Signing ${prepared.transactions.length} transaction(s)...`);

const signedTransactions = [];
for (const tx of prepared.transactions) {
  signedTransactions.push(await wallet.signTransaction(tx));
}

After:

const txList = Array.isArray(prepared.transactions)
  ? prepared.transactions
  : [prepared.transactions];

console.log(`Signing ${txList.length} transaction(s)...`);

const signedTransactions = [];
for (const tx of txList) {
  signedTransactions.push(await wallet.signTransaction(tx));
}

Full source: https://github.com/sirmos/Brickwarden/blob/main/src/brickkenRest.js

My Improvements

I could have special cased this one call and moved on, but the helper is shared across every write action in the project, so a narrow fix would only have delayed the next time this shape showed up somewhere else. The Array.isArray check normalizes the response once, at the one place all of them pass through, so every call benefits from the same guard instead of needing its own workaround.

I also logged the raw prepared response before touching it, rather than guessing from the error text alone. The error said "not iterable," which explains what broke but not why. Seeing the actual shape next to a working response made the real cause obvious in one comparison instead of several rounds of trial and error.

Thank you for reading!!!

I built a dApp that fixes the savings system my community has trusted for several years

sirmos — Fri, 10 Jul 2026 14:22:43 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

I grew up watching the women in my family do ajo.

Every month, a group of people pool money together. One person gets the full pot. Then the next. Then the next. No bank. No interest. Just trust.

It's been working in Nigeria for centuries.

But the trust part? That's where it breaks.

The collector - the person who holds everyone's money, can disappear the moment they've received their own payout. No receipt. No contract. No way to get your money back.

I know people who've lost hundreds of thousands of naira this way. And they still go back, because the system itself is genius. The only broken part is the human in the middle.

That's what drove me to build EsusuX.

EsusuX is a decentralized ajo protocol on Solana. It replaces the collector with a smart contract. The contract holds the money. Not me. Not a company. A program on the blockchain that has one job, follow the rules.

Here's how it works:

Someone creates a savings circle and sets the amount, number of members, and frequency
Members join by connecting their wallet and locking a small collateral deposit
Every round, members contribute USDC to the contract
The contract automatically pays out the full pool to that round's member
If someone defaults after receiving their payout, their collateral is slashed

No collector. No trust required. No one can run.

Demo

Live app: esusux.vercel.app

Smart contract deployed on Solana devnet:
Program ID: CG2XsN5oeS1QzEUn3cuaqJb67uaAXgxMpPYsD9Qv5wJp
Connect a Phantom or Solflare wallet, create a circle, and join one right now using devnet USDC from faucet.circle.com.

Code

sirmos / esusux

esusux

View on GitHub

How I Built It

I chose Solana because the math only works here.

A ₦2,000 weekly contribution cannot survive Ethereum gas fees. On Solana, the transaction fee is a fraction of a cent. Payments confirm in under a second. For a savings app targeting everyday Nigerians, that's not a nice to have. It's the whole thing.

The smart contract is written in Rust using the Anchor framework. Three core instructions power the protocol:

create_circle - the organizer sets contribution amount, number of members, and payout interval. Everything is locked onchain and immutable once set.

join_circle - members join by locking 10% collateral in USDC. The circle automatically activates when all slots are filled.

contribute_and_disburse - members send their contribution each round. The contract immediately disburses the full pool to that round's recipient based on join order. No manual trigger. No human decision.

The frontend is built with Next.js and connects to the program using Anchor's TypeScript SDK. Wallet connection uses the Solana wallet adapter, supporting Phantom and Solflare. Contributions use devnet USDC via Solana Pay, with a QR code members can scan to contribute directly from their phone.

The whole stack is open source.

Prize Categories

Best Use of Solana

EsusuX is built entirely on Solana. The core protocol lives in a Solana program written with Anchor. Every circle creation, member join, and payout disbursement is an on-chain transaction. Solana's low fees and fast finality are what make this viable for small everyday contributions, something that simply isn't possible on other chains.

Built with: Solana, Anchor, Rust, Next.js, USDC, Solana Pay, Phantom, Solflare, Jupiter Wallet

weekendchallenge #solana #web3 #nigeria #defi #EsusuX #weekendchallenge

How I Built a Digital Estate Manager with Vercel v0 and Amazon Aurora PostgreSQL published

sirmos — Wed, 17 Jun 2026 09:16:28 +0000

I created this piece of content for the purposes of entering the H0 Hack the Zero Stack Hackathon.

Live app: https://memoris-sigma.vercel.app

It started with a death in the family

Two years ago a close friend lost his father suddenly. His father was an organised man but when he died, the family discovered he had 17 online accounts nobody could access. A bank account with money in it. A crypto wallet with a seed phrase nobody could find. An email full of insurance policies and property documents, completely locked.

His wife spent four months writing letters to companies and crying on phone calls with customer support agents reading from scripts. Some accounts were closed with money still inside them. Some are locked to this day.

"He was the most organised man I knew," she said. "But he never thought about this."

Nobody does. We spend our whole lives building a digital world and we leave no instructions for the people who love us. When the H0 Hackathon came along, I knew exactly what I wanted to build.

I built Memoris.

What is Memoris?

Memoris is a digital estate manager. It helps you answer one simple question that nobody wants to think about but everyone needs to:

If I died tomorrow, would my family know what to do with my digital life?

With Memoris you can:

Add all your digital accounts: email, bank, crypto, streaming, social media
Write encrypted access instructions: passwords, PINs, seed phrases, recovery codes
Assign each account to a specific person who should receive it
Add trusted verifiers: people like your pastor, lawyer, or sibling who confirm your passing
Write last wishes: a personal message your family reads after you are gone

When you die, your verifiers receive a simple email with one button to click. When all of them confirm, the vault unlocks. Each beneficiary sees only what was assigned to them. Your wife gets the Gmail and the bank instructions. Your son gets the crypto wallet and the seed phrase. Your daughter gets the family photos folder.
Nobody has to guess. Nobody has to fight. Nobody has to spend four months crying on phone calls.

The problem is bigger than most people realise

When I started researching this, I thought it was a niche problem. I was wrong.

The average person today has over 100 online accounts. 4.9 billion people use the internet. Every one of them will die someday. And almost none of them have any plan for what happens to their digital life.

Think about what lives in your digital accounts right now:

Money in bank accounts, PayPal, Binance, Opay, cash apps
Memories photos, videos, messages that exist nowhere else
Documents insurance policies, contracts, receipts, medical records
Subscriptions still charging your family every month after you are gone
Businesses accounts for businesses your family might want to continue

Most of this disappears or becomes inaccessible. Companies have no standard process for death. Some require a death certificate. Some require a court order. Some just close the account and keep the money.

Real example: In 2021, a family in the UK discovered their father had over £40,000 in a crypto wallet. He had the wallet. Nobody had the seed phrase. The money is still locked today.

Memoris exists so that this never has to happen to your family.

How I built it

The frontend: Vercel v0 and Next.js

I started with v0.dev, Vercel's AI powered UI generator. I gave it a detailed prompt describing Memoris and it generated a complete Next.js application in under 60 seconds. A dark, elegant landing page. Clean cards. A sidebar navigation. A warm design that felt right for a product people would use during the hardest moments of their lives.

I then customised everything, switching to a warm dark brown with gold accents (#C9A86A) that feel premium and trustworthy. I used Playfair Display for the headlines because it feels timeless and dignified. Not clinical. Not corporate.

Stack: Next.js 16 · TypeScript · Tailwind CSS · Lucide icons · Vercel deployment

The database: Amazon Aurora PostgreSQL

For the database I chose Amazon Aurora PostgreSQL on AWS RDS. This was not an arbitrary choice.

Memoris handles deeply relational data. A user has assets. Each asset is assigned to a beneficiary. Each beneficiary is connected to a user. Verifiers are connected to users. The access flow that unlocks the right assets for the right person requires complex join queries with conditional logic. PostgreSQL handles all of this natively and elegantly.

I have five core tables:
users: id, name, email, password_hash, created_at

assets: id, user_id, asset_type, label, assigned_to, notes

beneficiaries: id, user_id, name, email, relationship

verifiers: id, user_id, name, email, confirmed, token

wishes: id, user_id, content, updated_at

Every table uses proper foreign keys with ON DELETE CASCADE so if a user deletes their account, everything cleans up properly.

Stack: Amazon Aurora PostgreSQL · AWS RDS · pg (node-postgres) · bcryptjs · SSL connection

Authentication

I built authentication from scratch using bcryptjs. When a user signs up, their password is hashed with a salt factor of 10 before it ever touches the database. The plain text password never gets stored anywhere. Simple, secure and appropriate for a product that handles sensitive information.

The API

I built five sets of API routes inside the Next.js app directory:

/api/auth/signup creates a new user with hashed password
/api/auth/signin verifies credentials and returns user data
/api/assets GET, POST, DELETE for the asset vault
/api/beneficiaries GET, POST, DELETE for beneficiary management
/api/verifiers GET, POST, DELETE for trusted verifiers
/api/wishes GET and POST for last wishes

Every route checks for a user ID in the request header before doing anything. If it is missing it returns a 401. The API is protected at the data layer, not just the UI.

The executor view: what family sees

One of the most important parts of Memoris is the executor view. This is the page beneficiaries access after the vault is unlocked. It shows them only their assigned assets, the access instructions, and the owner's last wishes.

I designed this page with maximum clarity and minimum friction. When someone is grieving they do not need to figure out a complex interface. They need one clear list: here are your accounts, here are the instructions, here is what they wanted you to know.

The vault unlocked banner at the top sends one message to the family: he thought of you. He prepared this. You are not alone.

Design decisions that matter

Why warm gold instead of blue

Most security apps use blue. Blue says trust me, I am a bank. But Memoris is not a bank. It is something much more human than that.

I chose warm gold (#C9A86A) and deep brown-black (#0a0908) because this is an app people use while thinking about death. It needs to feel warm. Trustworthy. Like a hand on a shoulder.

Why the verifier system matters

I could have built Memoris with a simple timer, if the user does not log in for 6 months, unlock the vault. But timers are dangerous. What if the user is on a long trip? What if they are in hospital?

The verifier system requires real people who actually knew the deceased to confirm. All of them must agree before anything unlocks. For something this important, that friction is a feature not a bug.

The hardest part of building this

The biggest challenge was not the code. It was the emotional weight of the product.

Every time I designed a new screen I had to ask: what is the person using this feeling right now? When someone fills in the last wishes form they are confronting their own mortality. When a family member opens the executor view they are probably crying.

Every word in the UI matters. Every button label. I rewrote the copy at least five times.

On the technical side, the trickiest part was the AWS Aurora connection. The default express configuration uses IAM only authentication which took several attempts to get working from Vercel's serverless functions. I ended up using a standard PostgreSQL RDS instance with password authentication over SSL. Simpler, faster and easier to debug.

The lesson: sometimes the path you are forced onto is the better path.

What I learned

v0 is a genuine superpower for hackathons. One detailed prompt and you have a production quality Next.js UI to customise instead of starting from scratch.

Aurora PostgreSQL is the right database for relational data. I considered DynamoDB but the moment I drew out the data model I knew it had to be PostgreSQL. Relational integrity matters here.

Build the emotional core first. The last wishes feature was the most important feature to build. Without it Memoris is just a password manager. With it, it is something a person would actually use, recommend to their parents, and be grateful exists.

What comes next for Memoris

AES-256 encryption for asset notes using a user controlled master key
Real email sending for verifier links using AWS SES
Two factor authentication for vault owners
Legal document uploads for wills and insurance policies
Multi language support starting with Yoruba, Igbo, Hausa and Ibibio for the Nigerian market

The Nigerian market is where I see the biggest immediate opportunity. Millions of families deal with digital estate problems every year and there is no product built for this context with local bank support and local languages.

Try it yourself

Memoris is live right now. Sign up, create a vault, add assets, set up beneficiaries and verifiers, and see the full executor view.

Live app: https://memoris-sigma.vercel.app

Source code: https://github.com/sirmos/memoris

You will spend years building your digital life. Spend one afternoon making sure the people you love can find it when you are gone.

That is what Memoris is for. Not for the person who sets it up. For the wife who is already grieving. For the son who just wants to carry out his father's wishes. For the daughter who wants to read her mother's last message.

Build for the people left behind.

Built for the H0 Hack the Zero Stack Hackathon · #H0Hackathon

How I Built a Clinical Trial Memory AI Agent with Qwen Cloud in 5 Weeks

sirmos — Tue, 09 Jun 2026 21:42:02 +0000

The Problem I Set Out to Solve

Clinical trials run for years. Patient data gets scattered across session notes, emails, and spreadsheets. When a doctor asks "what happened to this patient three months ago?", nobody knows fast enough. Adverse events get missed. Documentation takes hours.

I built CTMC (Clinical Trial Memory Coordinator) to fix that.

What CTMC Does

CTMC is a persistent AI memory system for clinical trial teams:

Every session note is chunked and embedded using Qwen's text embedding-v3 model
Stored as searchable semantic memory scoped to each patient and trial
Natural language queries are answered by qwen-max using RAG, grounded in real session data with source citations
An anomaly detector automatically fires safety alerts on new ingestions
One-click FDA adverse event reports generated from memory in seconds
Full compliance audit trail of every memory read and write

The Tech Stack

Qwen Cloud qwen-max for synthesis, text-embedding-v3 for semantic embeddings
Node.js / Express backend with custom memory engine
React + Vite frontend
Alibaba Cloud ECS (Singapore) for deployment
PM2 for process management

The Memory Pipeline

The core insight: don't store session notes as raw text. Instead:

Chunk notes into semantic units (adverse events, observations, protocol notes)
Embed each chunk via text-embedding-v3
On query, embed the question, rank chunks by cosine similarity
Feed top-k chunks to qwen-max with strict grounding instructions
Return answer with exact session date citations

This gives you a memory that never hallucinates every answer is traceable to a real session.

The Biggest Challenge

Getting the anomaly detector to work reliably. The first version silently returned hasAnomaly: false on every new session. The fix was tightening the JSON output format in the system prompt, Qwen was wrapping responses in markdown code blocks that broke JSON parsing.

The Killer Demo Moment

After ingesting 6 months of patient sessions showing ALT liver enzyme progression (22 → 24 → 31 → 52 → 89 → 112 U/L), asking:

"What adverse events has P042 had and are they getting worse?"

The agent recalled the full progression across all sessions, cited each date, and flagged the escalating hepatotoxicity, in under 3 seconds.

What I Learned

Qwen's text-embedding-v3 model produces high-quality embeddings for clinical text. The cosine similarity ranking consistently surfaced the most relevant chunks even across months of session history.

The qwen-max model with strict grounding prompts is remarkably reliable at staying within the retrieved context, crucial for clinical applications where hallucination is dangerous.

Try It

Live demo: http://47.84.200.111:3001/
GitHub: https://github.com/sirmos/ctmc
Hackathon: Qwen Cloud Global AI Hackathon 2026, MemoryAgent Track

Built in 5 weeks for the Qwen Cloud Global AI Hackathon. The memory grows smarter with every session and never forgets.

qwencloud #alibabacloud #ai #hackathon #clinicaltrials #nodejs #react #h0hackathon