DEV Community: Mialy333 🎧ྀི

My model gave my client an 82% risk of paying late. They paid 15 days early.

Mialy333 🎧ྀི — Sun, 18 Oct 2026 15:02:10 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

I'm a freelancer in Paris. When I send an invoice, I don't know whether the client will pay on time. I also never know how to word the reminder: too soft and I keep waiting, too firm and I risk the relationship.

Late Pay Radar is a small app for freelancers that runs on your laptop:

You add your invoices, as a CSV or as a text PDF exported from your invoicing tool.
TabPFN, a tabular foundation model, ranks the unpaid ones by risk of late payment.
You pick one. A local Gemma agent explains the risk and drafts a reminder in French or English: friendly before the due date, firmer after it.

Client names, amounts and payment history stay on the laptop.

The first user is me. I have one invoice on record: €1,725, issued on 30 June with 30-day terms, so due on 30 July.

Demo

The video (52 s, no sound) uses a fake invoice so no real client name appears on screen. A PDF is imported, its fields are extracted and confirmed, the risk table appears, and Gemma writes the explanation and the reminder. The wait in the middle (about 13 s) is local inference on my MacBook. At the end, ollama ps shows gemma4:e2b running on the GPU. My real invoice and what the app said about it are described further down.

There is no hosted version. Uploading your invoices to my server would defeat the point, so the app runs locally in 5 commands (see the README).

Code

Mialy333 / late-pay-radar

Predicts late invoice payments for freelancers, locally, with TabPFN + Gemma

late-pay-radar

Ranks your open invoices by late-payment risk and drafts the right reminder — entirely on your own machine (TabPFN + a local Gemma model via Ollama). Demo video: https://youtu.be/sccG2NXpBWw

Quick start

git clone https://github.com/Mialy333/late-pay-radar && cd late-pay-radar
uv sync
ollama pull gemma4:e2b
uv run python scripts/download_barnet.py && uv run python scripts/build_barnet_dataset.py
uv run streamlit run app.py

Before that last command, you need a TABPFN_TOKEN in .env — see the next section.

TabPFN account (one-time)

The risk model (TabPFN) needs a one-time license acceptance before it will run locally, even for the demo data:

Create a free account at https://ux.priorlabs.ai.
Accept the TabPFN-3.5 license (non-commercial use) on the Licenses tab.
Copy your API key from https://ux.priorlabs.ai/account.
cp .env.example .env and put the key in as TABPFN_TOKEN=<your key>.

This is a one-time step: once accepted, it's cached locally and no further account/network interaction is needed (see "Why local?"…

View on GitHub

The code is MIT. The public dataset comes from the London Borough of Barnet under the Open Government Licence v3.0.

How I Built It

Stack: TabPFN-3.5 (local weights) for the risk score, Gemma (gemma4:e2b) through Ollama for the text, Strands Agents in Python for the agent and its tool, Streamlit for the interface, pdfplumber to read PDFs locally.

Finding real data

Freelancers don't publish their invoices, so I looked for public data. The London Borough of Barnet publishes late-payment reports: 1,561 supplier invoices with issue date, due date and actual payment date. Of the paid ones, 77% were paid more than 7 days late. These are suppliers waiting for a large client to pay them, which is the freelancer's situation.

I only used information available on the day an invoice is issued: amount, payment terms, the client's past behaviour, month and weekday. Barnet's dispute, hold and "paid within terms" columns describe what happened after the invoice was sent, so using them would have given the model the answer.

The backtest

I trained on older invoices and tested on the 446 most recent ones.

On the first run, TabPFN predicted "late" for almost everything. It recognised only 4 of the 123 invoices paid on time. On my synthetic test data it did the opposite and predicted "on time" every time. In both cases it was mostly repeating the most common answer.

The problem was my evaluation. I added a baseline that always predicts the most common answer, measured ranking quality with ROC-AUC (a freelancer mainly needs to know which invoice to chase first), and chose the decision threshold on a validation slice instead of the test set.

Model	Balanced accuracy	ROC-AUC
Always the most common answer	0.500	n/a
Simple rule: "this client was late before"	0.699	0.687
TabPFN, no tuning	0.598	0.688

TabPFN ranks invoices about as well as the simple rule, and makes worse yes/no decisions. It doesn't beat it.

Then I split the test set by how much history we have on the client:

Test subset	TabPFN AUC	Simple rule AUC
New clients, fewer than 3 past invoices (186)	0.629	0.584
Known clients, 3 or more (260)	0.766	0.779

The simple rule needs history. Without it, TabPFN can still use the amount and the payment terms. The gap is small and, on 186 invoices, not statistically solid. I still used it to design the product: new clients get the TabPFN score with a "⚠ low confidence" label, known clients get their own track record.

The agent

The Strands agent has one tool, get_invoice_risk. Gemma writes the explanation and the reminder. Most of the bugs I hit were fixed the same way, by moving the work that has one right answer out of the model and into code:

Asked to find the riskiest invoices in a list of 78, Gemma picked from the middle. The ranking is now computed in code and shown as a table.
It called an invoice that wasn't due yet "unpaid" and wrote a firm reminder. Due status, amounts and dates are now computed in code and passed to the model.
It skipped the required note about where the training data comes from. The code now adds it every time.
It sometimes left the amount or the date out of the reminder. A check now looks for both and asks for one rewrite. In testing, the first draft failed this check twice out of two, and the rewrite fixed both.

PDF import

My real invoice is a PDF, so in the morning I typed it into a CSV by hand. That's why PDF import was the first feature I asked for. The text is extracted locally, Gemma pulls out the fields as JSON, the code checks them, and you confirm them in an editable table before anything is scored. On my real PDF, Gemma read the due date correctly as 30 July. I was the one who had typed 31 July in my CSV.

What broke

My own invoice. Scored as if it had just been issued on 30 June, it got an 82% risk of late payment. My client paid 15 days early. TabPFN learned from UK public-sector suppliers, 77% of whom were paid late, and knew nothing about my client, my sector or my country. For a client with no history, the score mostly reflects that 77%. The app now shows this in a banner that the code adds, so the model can't leave it out: "Model trained on UK public-sector supplier invoices; transfer to other clients is uncertain."

A safety check that let a wrong answer through. To cut the 13-second wait, I merged the explanation and the reminder into a single Gemma call. Latency dropped to 4 seconds, and the log said Tools called: none. Gemma never looked up the invoice. It wrote "$1,500.00" and "October 15, 2026" instead of €3,250.00 and 10 May 2026. My check didn't catch it because it only ran when the tool had been called. I went back to two calls and changed the check: the app now looks up the invoice itself, always compares the reminder against it, and shows no reminder if the comparison fails.

My README. I cloned the repo into an empty folder and followed only the README. It crashed. The raw Barnet files were excluded from git, uv sync and ollama pull weren't mentioned, and the TabPFN token was explained at the bottom although the page needs it to load. Barnet's server also refused the download from Python's default user agent. After the fixes, a fresh clone starts in 5 commands.

Why Does Open Innovation Matter?

Client data stays on the laptop. TabPFN's weights are cached locally. I tested it with all network traffic blocked: scoring still works, same result, 0.29 s. I also turned off Streamlit's usage statistics.
No cost per use. There is no per-token bill. A tool priced at a few euros a month can't absorb API costs on every reminder.
I could check the claims myself. The packages are open, so I could read the code and test that nothing is sent over the network instead of relying on a privacy policy.
The parts can be swapped. Gemma, the agent framework and the scoring model are independent. The simple rule came close to TabPFN, so replacing the scorer is a real option.

One limit matters for a side hustle: TabPFN-3.5's weights are under a non-commercial licence. That's fine for this prototype. Selling the tool would require Prior Labs' commercial licence or a different scorer, and I'd rather know that before the first paying customer.

The first user

I like how warm the reminders are. The 82% left me with a question I'm still asking: how can anyone really measure that, and through what lens? Still, it gives me an estimate of the risk. It helps me organise myself, saves me time and, when needed, helps me find common ground with a client.

Part of the answer: 82% means that among the Barnet invoices that look like mine (30-day terms, similar amount, no client history), about 8 in 10 were paid late. It describes someone else's data, not my client. A single invoice also can't confirm or contradict a probability. That takes many invoices: of all those scored around 80%, about 80% should end up late. So the next step is to learn from my own payment history.

What I asked for as a user: PDF import and warmer reminders that explain why paying on time helps and offer to discuss a schedule. Both were built this weekend. Next: photos and scanned invoices, and scores based on my own history instead of Barnet's.

Would I pay for it? Yes, if it's secure and the automation saves me real work. My ceiling is €19.99 a month. At that price, a local model with no per-use cost is what makes the numbers work, once the TabPFN licence question is settled.

My Agent Session

Built with Claude Code over three saved sessions: the backtest, the agent, and the interface with the safety-check bug.

Late Pay Radar: UI, PDF import and a guardrail that failed open

You

Build a one-page web interface for the invoice risk tool: pick a data source (a public demo dataset or your own invoices), see a ranked table, then pick one invoice and a language to get an explanation and a reminder from the local agent.

Agent

Built it as a single-page app. The ranking table is computed entirely in plain code, not by the language model, so it's deterministic and instant. The agent is only called once a specific invoice is selected, to explain its risk and draft a reminder. Also checked, before claiming the tool runs entirely locally, whether the underlying risk model or the web framework quietly phone home -- confirmed neither does once set up correctly, and disabled the one anonymous usage-telemetry setting the web framework has by default.

You

Let people also import their own invoices from a PDF, not just a spreadsheet. Extract the text locally, reject scanned image-only PDFs with a clear message, have the local model pull out the structured fields as data, validate them, and let the person review and correct everything in an editable table before anything gets scored. Nothing should ever be written to disk.

Agent

Built that pipeline: local text extraction first (scanned PDFs are caught and rejected immediately, before even trying the model), then the local model is asked to return the fields as structured data, which is checked in code (valid dates, positive amount, sane date ordering) with one retry if something's off and only the still-broken fields blanked out -- never the whole record. Everything stays in memory; confirmed by generating and testing with a fake sample invoice, never anything real.

You

Fix how the reminder reads: it should come from the freelancer who sent the invoice, to the client who owes the money -- first person, mentioning the invoice and amount and ending with a signature line. The explanation should also be in plain everyday words in whichever language was requested, not technical field names. And make sure the displayed amount is formatted the way each language actually writes money, not just by currency.

Agent

Fixed the perspective (the explanation was accidentally implying the user received the invoice rather than sent it -- corrected in both languages). Explanations now read in plain language, in whichever language was asked for. The displayed amount now formats itself to match the reply's language rather than always defaulting to one style, and the validator that checks a drafted reminder for the real figures was updated to recognize either language's way of writing the amount and the date, since the small local model doesn't always pick the one you'd expect.

You

Make the reminders warmer and more human -- greeting, a plain-language reason timely payment matters, an offer to help or discuss a schedule if timing is tough, and only mention a possible penalty when the invoice is genuinely overdue, never inventing a specific number. Then separately: fix the interface so switching the language doesn't lose or re-trigger anything, and make sure repeated interactions stay fast.

Agent

Updated the reminder style and added a line-by-line check: while testing I found the small model doesn't always write an English date the way the French one does, so loosened the check to accept either common ordering rather than forcing one. For the interface, grouped the invoice/language/button controls so changing the language alone no longer reruns anything until the button is actually pressed, cached the underlying model connection and the computed table so repeat interactions are instant, and made results stick around per invoice-and-language combination instead of disappearing on unrelated screen updates. Also deliberately tried to reproduce the exact scenario the user was worried about (switching language right after confirming an import) using an automated interface-testing tool rather than guessing, and found no error either before or after the change.

You

Reorder the reminder so it leads with the concrete facts (invoice number, amount, due date) right after the greeting, before the explanation of why it matters. Separately, try combining the two model calls (explanation and reminder) into a single call to cut latency.

Agent

Reordered the reminder as asked. The single-call experiment did cut latency roughly in half when it worked -- but it made the small local model noticeably less reliable: in some runs it skipped actually looking up the real invoice data at all and just invented numbers in the reminder, and because the safety check only ran when the lookup had actually happened, a run where the model skipped it sailed through uncaught. That's a guardrail that fails OPEN -- it protects you only when things already went right, which defeats the point.

You

Revert to the two-call approach. And fix the guardrail properly: fetch the real invoice data in code BEFORE calling the model at all, and always check the drafted reminder against that real data, whether or not the model's own lookup happened. If it still doesn't check out after one retry, don't show it -- show a clear error instead. Same for a visibly broken explanation.

Agent

Reverted to two separate calls. The real fix: the invoice's true numbers are now fetched directly in code, independent of anything the model does, and the reminder is always compared against those real numbers -- a run where the model never looks anything up now correctly fails the check instead of slipping through. If a reminder still doesn't check out after one retry, or an explanation comes back obviously broken (too short, or shouting in capitals), neither is shown -- a clear error is shown instead. Tested three times with a fake invoice: every reminder now correctly contains the real amount and date. One remaining honest finding: the explanation text itself sometimes came back as a flat 'I couldn't find that information' even though the real lookup clearly happened (the reminder had the right numbers) -- a model reliability quirk the length/formatting check doesn't catch, since the refusal is itself a normal-looking sentence. Flagged rather than hidden.

Prize Categories

TabPFN (Prior Labs): the risk scorer, backtested against baselines on real invoices, with separate handling for new clients.
Gemma: explanations, reminders and PDF field extraction, all running locally through Ollama.

I built a customer support agent on Amazon Bedrock AgentCore — and it refused to say my name

Mialy333 🎧ྀི — Mon, 12 Oct 2026 08:30:00 +0000

I spent ten years in asset management, most of it translating what portfolio managers and quants built into something clients could actually follow. Now I build agents. It turns out the job is weirdly similar: an agent is mostly a translation layer between a person asking a vague question and a set of systems that only understand precise ones.

This is the second project of the AWS AI & ML Scholars — Future Agent Engineer track: a customer support agent for a fictional e-commerce store, running on Amazon Bedrock AgentCore. Here's how it's put together, the three things that tripped me up, and one bug that passed every test.

👉 Repo: github.com/Mialy333/agentcore-customer-support-agent

What the agent does

One conversational entrypoint, six capabilities:

Ask	What answers it
"Where's my order ORD-001?"	AgentCore Gateway (MCP) → API Gateway → Lambda
"Refund my Kindle"	AgentCore Gateway (MCP) → Lambda
"What does Platinum tier get me?"	Bedrock Knowledge Base (RAG)
"Do you remember me?"	AgentCore Memory via a Strands hook
"What's my discount with 4,250 points?"	Code Interpreter (sandboxed Python)
"What's on this web page?"	Browser Tool

It runs on AgentCore Runtime (serverless, direct code deploy, Python 3.13), uses the Strands Agents SDK, and reasons with Amazon Nova 2 Lite.

The whole agent fits in a single main.py. The entrypoint is short because each capability is a tool or a hook:

@app.entrypoint
async def invoke(payload, context=None):
    user_input = payload.get("prompt", "")
    actor_id = payload.get("customer_id", "anonymous")
    session_id = payload.get("session_id") or str(uuid.uuid4())

    memory_hook = MemoryHook(actor_id, session_id, memory_client, MEMORY_ID)
    browser = AgentCoreBrowser(region=REGION)
    tools = [search_knowledge_base, calculate_loyalty_discount, browser.browser]

    gateway_client = MCPClient(lambda: streamable_http_client(GATEWAY_URL))
    with gateway_client:
        all_tools = tools + gateway_client.list_tools_sync()
        agent = Agent(model=model, tools=all_tools,
                      hooks=[memory_hook], system_prompt=SYSTEM_PROMPT)
        return agent(user_input).message["content"][0]["text"]

Nine tools reach the model: three local ones, plus six discovered at runtime from the Gateway over MCP. The agent doesn't know (or care) that get_order lives behind API Gateway while initiate_refund is a bare Lambda — it just sees an MCP tool list.

1. Gateway: two very different backends, one MCP endpoint

This was the part I found most "production-shaped". The two Lambdas have nothing in common:

order-tracker is a classic API Gateway proxy Lambda. It routes on event["resource"] and pathParameters.
refund-processor is called directly by the Gateway. It never sees an HTTP request; it reads the tool name from the Lambda client context:

raw_tool = context.client_context.custom.get("bedrockAgentCoreToolName", "")
tool = raw_tool.split("___", 1)[-1]   # "refund-processor___initiate_refund" → "initiate_refund"

AgentCore Gateway wraps both as targets of one MCP server. For the REST API, each operation ID (get_order, get_customer, get_customer_orders) becomes a tool name. For the Lambda, you paste a JSON tool schema.

Gotcha #1 — target names reject underscores. I named my targets order_tracker and refund_processor, matching the Lambda files. The Gateway was created fine… and then both targets failed: the name must match ([0-9a-zA-Z][-]?){1,100}. Hyphens only. order-tracker and refund-processor went through.

Before writing any agent code, npx @modelcontextprotocol/inspector against the Gateway URL is the fastest way to confirm all six tools are actually exposed.

2. RAG: the boring part that just works

The knowledge base is a single product_catalog.txt (products, return windows, refund timelines, loyalty tiers) uploaded to S3 and synced into a Managed Knowledge Base. The tool is a thin wrapper around the Retrieve API:

resp = _bedrock_runtime.retrieve(
    knowledgeBaseId=KB_ID,
    retrievalQuery={"text": query},
)
chunks = [r["content"]["text"] for r in resp.get("retrievalResults", [])
          if r.get("content", {}).get("text")]
return "\n---\n".join(chunks)

Asked about the Platinum tier, the agent returned exactly what the catalog says — free same-day shipping, 15% discount, priority support — instead of whatever the model half-remembers about loyalty programs in general. That's the whole point of RAG: answers you can trace back to a document.

3. Memory: a hook, not a prompt rebuild

AgentCore Memory is configured with two built-in strategies:

Semantic → cs_agent/{actorId}/facts
User preference → cs_agent/{actorId}/preferences

The agent saves raw conversation events; AgentCore extracts durable facts and preferences from them in the background.

On the agent side, I used a Strands HookProvider with two callbacks:

def register_hooks(self, registry):
    registry.add_callback(MessageAddedEvent, self.retrieve_customer_context)
    registry.add_callback(AfterInvocationEvent, self.save_support_interaction)

Before the model sees a user message, the hook queries every namespace and prepends a Customer Context: block to that message.
After the agent answers, it saves the (user, assistant) pair with create_event.

The design choice I like: the agent's reasoning loop never knows memory exists. It just receives a slightly richer message. Retrieval and saving each live in their own method, and tool-result messages are skipped so memory is only queried on real user turns.

Gotcha #2 — the agent refused to say my name

The test: in session A, "Hi, I am Jane. I prefer concise responses." Wait 30 seconds for extraction. In session B, "Do you remember my name and communication preference?"

First run: it recalled "prefers concise responses"… and then declined to tell me my name, explaining it didn't have access to personal identification details for security reasons.

Nothing in my code blocked it. The memory record was right there in the context. The model itself decided a name looked like sensitive data and got cautious — about a name the customer had volunteered minutes earlier.

The fix was a few sentences in the system prompt: the Customer Context block contains facts the customer previously and voluntarily shared, and stating them back is expected behavior. After that:

It remembered Jane, the preference, and her two recent orders. Lesson: guardrails baked into a foundation model can misfire in directions you never asked for, and sometimes prompt engineering means removing caution rather than adding it.

4. Code Interpreter: don't let an LLM do the arithmetic

Loyalty math has just enough rules to go wrong: points redeem in 500-point blocks ($5 each), capped at 50% of the order, then a tier discount (Gold 10%, Platinum 15%) applies, then you earn points on what you paid.

Instead of trusting the model, calculate_loyalty_discount generates a small Python program and runs it in the AgentCore Code Interpreter sandbox:

with code_session(REGION) as session:
    response = session.invoke("executeCode",
        {"code": code, "language": "python", "clearContext": True})

Gold member, 4,250 points, $150 order:

4,000 points redeemable → $40
$110 × 10% Gold discount → $11
Final total $99.00, earns 99 points → 349 points left

If the sandbox is unavailable, the tool falls back to a tier-only calculation and says so in its output, rather than failing silently or letting the model guess.

5. Browser: one line

browser = AgentCoreBrowser(region=REGION)
tools = [..., browser.browser]

AgentCore runs a managed headless browser; the agent got the live page title from udacity.com. The only real work was IAM.

Deploying (and Gotcha #3)

The course intentionally uses the Python Bedrock AgentCore Starter Toolkit:

uv run agentcore configure --entrypoint main.py --name customer_support_agent \
  --deployment-type direct_code_deploy --runtime PYTHON_3_13 --disable-memory
uv run agentcore deploy
uv run setup_permissions.py

setup_permissions.py reads the resource IDs from main.py as text (with ast, never importing the agent), checks the account and role match the deployment, then attaches one inline policy scoped to this Knowledge Base, this Memory and the managed browser. Least privilege, rerunnable.

Gotcha #3 — region drift. One configure run silently picked up us-west-2 while every resource lived in us-east-1. Read the configuration summary before you deploy.

Side note: every invoke now prints a notice that the Starter Toolkit is no longer supported in favor of the npm @aws/agentcore CLI. Don't install both — they ship the same agentcore binary.

The bug my tests didn't catch

All six scenarios passed. Then I re-read the refund output more carefully:

Refund ID ✅, APPROVED ✅, "3–5 business days" ✅… and Refund Amount: $0. Plus a confident "you don't need to return anything, this was a digital product" — about a physical Kindle.

What happened: amount is optional in the refund tool's schema, the Lambda defaults it to 0, and the model never called get_order to look up the $139.99 total first. Then it filled the gap with a plausible story.

The test checked for the shape of the right answer, not for the answer being right. Fixes I'd ship in v2:

make amount required in the schema, or better, have the Lambda look the amount up server-side so the model can't get it wrong;
instruct the agent to read the order before acting on it;
assert on values, not keywords, in the tests.

This is the kind of thing I'd rather find in a sandbox than in a customer's bank account.

If this went to production

A real authorizer on the Gateway. The project uses the NONE inbound authorizer to stay focused on tool integration. That's fine for a sandbox and unacceptable for anything else: JWT/OAuth.
Retries and timeouts on the MCP connection.
Tighter IAM than the auto-created runtime execution role.
Cost monitoring. The vector store behind the Knowledge Base kept billing the whole time I was building, whether I was testing or not. Tear everything down when you're done (agentcore destroy, then Gateway, Memory, KB, vector store, S3, API Gateway, Lambdas).

Takeaways

The hardest part of AgentCore isn't the Python. It's getting Gateway, Memory, the Knowledge Base, the Code Interpreter and the Browser to agree with each other — same region, same protocol, same IAM role.

And the most interesting failures weren't infrastructure failures. They were the model being too careful with a name, and not careful enough with a refund amount. Which is, honestly, the same lesson I learned explaining portfolios to clients: the risk is rarely in the system you can see; it's in the gap between what someone asked and what got executed.

The full code, architecture diagrams, all six test screenshots and a 43-step setup walkthrough are in the repo:
👉 github.com/Mialy333/agentcore-customer-support-agent

I'm Mialy, building at the intersection of AI agents and digital assets as @ellebuild. If you've hit other AgentCore gotchas, I'd love to hear them in the comments.

I built an AI that sends me on autumn walks. Then I got sick.

Mialy333 🎧ྀི — Sat, 10 Oct 2026 08:10:00 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

Every morning, a small bot on my laptop picks five trees in Paris that are changing colour, checks the weather, and sends me a walk on Telegram. Reading it takes about 20 seconds. The walk takes about an hour. That ratio is the whole idea.

What I Built

Autumn is my favourite season. I'm fascinated by the colours, and there's a particular atmosphere to it, something warm. I love walking through the streets of Paris with a bit of music in my ears, just feeling those vibes. It's also the season of soups and comfort food, and of going out for a hot chocolate in a coffee shop with fogged-up windows, with the people you love.

So this week, I built something to make sure I don't spend this autumn behind a screen.

Autumn Walks is a Telegram bot that sends me one walk every morning at 8:30:

a line of weather advice (umbrella or not, the driest hour of the afternoon)
3 to 5 trees that turn red, orange or gold in October, with their street and their autumn colour
the total distance, an honest walking time, and a Google Maps link for the loop

It never sends the same streets two days in a row. It works in French and English. It is for one person: me.

The trees come from Paris open data. The city publishes every tree it manages: 220,174 of them. I kept 2,065: the species with strong autumn colour (ginkgo, liquidambar, Persian ironwood, maple, oak) in five central arrondissements, and only trees you can actually walk up to: streets, public gardens, cemeteries. No school yards. (An early version sent me to a tree inside a nursery.)

Demo

Here's what reached my phone on Thursday morning, in French, with nobody touching the laptop:

In English:

Oak, 73 rue de Provence, copper brown

Persian ironwood, rue Milton, red to orange

Liquidambar, 3 rue de la Jussienne, red to purple

Liquidambar, Jardin Nelson Mandela, red to purple

Maple, 8 rue de la Banque, red or orange

Total distance: 3.9 km, walking time: 65 minutes.

The part I didn't plan

On Thursday I got sick. Properly sick. I didn't take a single one of these walks.

It frustrated me a lot, because when someone gives me a challenge, I love seeing it through to the end. But my health comes first.

On Friday, the bot went silent. The log had no entry at all. My Mac had been shut down overnight, and macOS launchd catches up on a job missed during sleep, but not one missed while the machine is off. The bot built to get me outside was stuck inside with me.

So this post is about a tool I built and tested, that ran on its own, and that I haven't used yet. The first walk is waiting for me when I'm back on my feet.

Code

Mialy333 / autumn-walks

Plan short autumn walks past colourful Paris trees with a local LLM agent (Strands + Gemma 4 E2B on Ollama)

autumn-walks

Ask "Where should I go for a walk this fall?" and get a short message, ready to send, inviting you on an autumn walk in Paris past trees with strong autumn colour (ginkgo, sweetgum, Persian ironwood, maple, oak). It runs on a small local model.

Design principle: the LLM writes, the code does the geography.

How it works

flowchart LR
    Q["Question<br/>or daily 8:30 job"] --> A["Strands agent<br/>Gemma 4 E2B via Ollama"]
    A --> W["get_weather<br/>Open-Meteo"]
    A --> F["find_autumn_trees<br/>SQLite: Paris trees"]
    A --> B["build_walk<br/>Python: stops, distances, Maps link"]
    H[("Walk history<br/>SQLite")] -- "skip recent streets" --> B
    W --> A
    F --> A
    B --> A
    A --> M["Message<br/>checked before sending"]
    M --> T["Telegram"]
    M -- "record walk" --> H

A Strands Agents agent running Gemma 4 E2B on Ollama uses three tools:

get_weather: this afternoon's temperature, rain probability and wind from Open-Meteo (no API key), plus whether to take…

View on GitHub

How I Built It

Stack, all open and all local except two HTTP calls:

Model: Gemma 4 E2B, running locally with Ollama
Agent framework: Strands Agents (Python)
Data: Paris open data "Les arbres" (ODbL), filtered once into SQLite
Weather: Open-Meteo (free, no API key)
Delivery: a Telegram bot, triggered by a launchd job every morning

Step 1: check that a small model can call tools at all

Before writing anything else, I ran a spike: Gemma 4 E2B, one fake weather tool, one question, three runs. It called the tool correctly 3 times out of 3, in 3 to 7 seconds. That was the main risk of the week, and it took an evening to clear.

Step 2: the design principle that made it work

My first agent let Gemma do everything: search the trees, pick the stops, compute the distances. It failed in instructive ways:

Without a system prompt, it called no tools at all, in 3 runs out of 3, and said it couldn't plan routes.
When it picked the stops itself, it chose far-apart rare trees and produced 4.8 to 5.5 km loops for a 40-minute walk, retrying up to 4 times.
It invented places. One walk included the Jardin du Luxembourg, which is not in any of the arrondissements I loaded.
It got numbers wrong: it called a 1.2 km loop "about 3 km" and mislabelled distances.

So I split the work:

The LLM writes. The code does the geography.

Python now searches the trees, picks the best set of 3 to 5 stops that fits the distance limit (most species first, then the shortest loop), computes every distance and the walking time (straight-line distance × 1.3 for real streets), and builds the Maps link. Tree names and autumn colours come from a fixed dictionary. Gemma reads all of that and writes a short, friendly message in French or English. It never invents a tree, a colour or a number.

Before a message is sent, the code checks it: the walk was actually built, the exact link is present, the start point is right, the wind is mentioned, no street repeats from the last two walks, under 150 words. If a check fails, the agent is told why and tries again, at most twice. Every retry reason is logged.

Current results: 11 checks out of 11 on every test run, 15 to 21 seconds per walk on a laptop.

Step 3: memory

The first daily version sent the same walk every day: same start, same trees. A small SQLite history fixed it. The agent now skips the streets of the last two walks. (Skipping only the trees wasn't enough: it produced the same route with the tree next door.) The history stays on my machine and never goes to GitHub.

Why Does Open Innovation Matter?

It costs nothing to run. Inference is local. The only network calls are the weather and the Telegram message.
My location and habits stay mine. A hosted model would receive my starting point and my walking history every single day. Here they never leave the laptop. To be precise: the Telegram message itself goes through Telegram's servers, and the weather call sends the coordinates of the Opéra, a public landmark I chose on purpose rather than my home.
The data is open too. The trees are Paris open data under ODbL. Any city that publishes its trees could get the same bot by swapping one file.
I could see and change everything. When the agent misbehaved, I didn't have to guess what a black-box API was doing. I moved the geography out of the model and into code I can test. Swapping the model is one line of config.

What Broke

The bot went silent on the day I got sick (see above): a shut-down Mac doesn't run missed launchd jobs.
My agent session uploads were blocked. Saving the coding sessions to DEV with DevRelay hit a Cloudflare 403 whenever the transcript contained code. I published lighter versions without code; the code is in the repo.
My Gmail address was in my first commit, both as the commit author and in pyproject.toml. Caught before the first push, fixed with a squash and GitHub's noreply address.
The Maps link was cut in half in Telegram, because of the | separators between waypoints. Encoding them as %7C fixed it.
Open-Meteo returned 503 "overloaded" while I was building, so the weather tool now retries, and tells the agent honestly when the weather is unavailable.

What's Next

Take the walks. All of them.
Let friends subscribe, each with their own language and starting point.
Make the colour depend on the date: "starting to turn" in early October, "golden" later on.

Want your own?

There's no public bot to message: it runs on one laptop for one person. But the repo is built to be adapted: your start point, your language, your send time. If your city publishes its trees as open data, tell me in the comments. I'd love to know where this could go next.

My Agent Session

The whole build was done with a coding agent in my terminal. Here's the session where the bot got its memory and its Telegram voice:

Autumn walks: walk memory and a Telegram morning message

You

Keep the 4 km limit. Step 4a: give the agent a memory. Save each walk (date, start, trees, loop length) and leave out the trees of the last 2 walks, then plan 3 walks in a row and show they differ. Step 4b: Telegram. I created a bot and put its token in an environment file; never print that file, make sure it is ignored by git, find my chat id and save it there. Add a command that plans a walk and sends it to my chat, schedule it every morning at 8:30 without turning it on yourself, and send one real message now.

Agent

▸ Bash Check the secrets file without printing it

Input

$ Check the secrets file without printing it

Output

Never committed, but not ignored by git yet. Added it to the ignore list. Only the variable names were ever shown.

▸ Bash Plan 3 walks in a row, leaving out the trees of the last 2 walks

Input

$ Plan 3 walks in a row, leaving out the trees of the last 2 walks

Output

All checks pass, but the route is the same each time: the same four streets, just with the neighbouring tree.

Leaving out tree ids changes nothing a walker would notice. The next walk now skips the streets and parks of the last 2 walks instead.

▸ Bash Plan 3 walks in a row again

Input

$ Plan 3 walks in a row again

Output

Three different routes with no shared street, 3.5 to 4 km each, all 11 checks passing. One run needed a retry because the model skipped the walk-building step; the send check caught it and the reason was logged.

The walk history lives in its own small database that is not committed, so the tree data stays shareable and the history stays private. A walk is only recorded after it is actually sent, and tests use a throwaway history.

▸ Bash Look up the chat id from the bot's updates

Input

$ Look up the chat id from the bot's updates

Output

No messages found. The token worked and no webhook was set, so the message had probably gone elsewhere or expired.

The daily job was prepared but not turned on, from a template so the repository holds no personal paths. Everything was paused until the chat id was available.

You

I sent the bot two new messages. Try again, and if nothing comes back, check whether an earlier call acknowledged my messages. Then send the real walk, commit and push.

Agent

▸ Bash Look up the chat id again

Input

$ Look up the chat id again

Output

Found, from a private chat, and saved without being printed. No earlier call had acknowledged the messages.

▸ Bash Send the real walk

Input

$ Send the real walk

Output

Sent after one logged retry: a 3.5 km, 55-minute loop from Opéra Garnier, recorded as the first walk in the history.

▸ Bash Scan the changes for the token, the chat id and personal data, then commit an...

Input

$ Scan the changes for the token, the chat id and personal data, then commit and push

Output

Nothing found. Pushed.

You

Turn on the morning job.

Agent

Loaded: it runs every day at 8:30, or on wake if the Mac was asleep. The first walk goes out tomorrow and will avoid today's streets.

You

Add a language option for a single run and an option to send without recording the walk, then send me one walk in English without recording it, for a screenshot.

Agent

▸ Bash Send one English walk without recording it

Input

$ Send one English walk without recording it

Output

Sent: a 3.9 km loop through rue de Provence, rue Milton, rue de la Jussienne, Jardin Nelson Mandela and rue de la Banque. The history still had exactly one walk afterwards.

Takeaways: memory has to be about what the user experiences, which here means streets rather than tree ids. Secrets stay safe by never printing them, checking the ignore list before anything else, and scanning every commit against the real values. And a check before sending turns a small model's occasional slip into a logged retry instead of a wrong message on someone's phone.

Prize Categories

Best Use of Gemma: Gemma 4 E2B runs locally and is the agent at the core of the project.

My support chatbot scored 0.92. It was also lying to customers.

Mialy333 🎧ྀི — Thu, 08 Oct 2026 22:00:00 +0000

Twelve of my thirteen test prompts scored a perfect 1.00. Two independent evaluation runs agreed: 0.92 correctness. No message routed to the wrong place, both prompt-injection attempts refused.

And yet, in one conversation, my chatbot told a customer:

"I have filed a bug report with ticket ID TIX-345678."

That ticket did not exist. Nothing had been written to the database. The customer would have walked away believing their bug was logged.

This is the story of how I built that chatbot, why the score couldn't see the problem, and what I check now instead.

The project

I'm going through the Udacity × AWS Agent Engineer Nanodegree. The first project: a customer-support chatbot for a fictional online shop that handles three kinds of messages.

Bug reports: collect a description, steps to reproduce, and the environment, possibly over several turns, then file a ticket.
Platform questions (orders, shipping, returns, payments): answer only from the shop's FAQ.
Anything else: politely hand off to a human support line.

One twist: Bedrock Agents Classic, which the course was originally designed around, closed to new customers on 30 July 2026. So the project runs on its successor, the Amazon Bedrock AgentCore managed harness.

The other twist, and the actual point of the exercise: there's no classifier and no routing node. All of the routing, information-gathering, and grounding behaviour lives in a single system prompt.

Architecture

Customer ──► chat.py ──invoke_harness──► AgentCore managed harness  ◄──► Amazon Nova Pro
                                              │  (system_prompt.txt + FAQ)     temp 0, topK 1
                                              │
                                    tool call: bugreports___create_bug_report
                                              ▼
                                       AgentCore Gateway (MCP, IAM auth)
                                              ▼
                                      Lambda create_bug_report ──PutItem──► DynamoDB

The pieces:

Harness: AgentCore runs the agent loop: model calls, session state, tool execution. I supply the prompt; the FAQ is injected at a {{FAQ}} placeholder when the harness is created.
Gateway: exposes a Lambda as an MCP tool. The model sees it as <targetName>___<toolName>, three underscores.
Lambda + DynamoDB: validates that all three fields are non-empty, writes the ticket, returns a UUID ticketId.
Everything as code: two CloudFormation stacks (tool + testing) and a few boto3 scripts. Iterating on the prompt is just: edit the file, re-run create_harness.py, open a new chat session.

The model is pinned to us.amazon.nova-pro-v1:0 with greedy decoding (temperature 0, topK 1), which AWS recommends for reliable tool calling with Nova.

Routing with nothing but words

Treating routing as a classification problem inside the prompt worked better than I expected. The prompt tells the model to pick exactly one category before writing anything, and never mix categories.

The hard part is the boundary. Is "my card was declined" a bug? Is "the mug arrived cracked"? I ended up with 15 explicit tie-breakers, for example:

An error or crash on the checkout page → bug.
A declined card → platform question (payments).
An item that arrived damaged → platform question (returns): the software worked, the order didn't.
Search returning nothing for a product that clearly exists → bug.

And one fallback principle for everything else: if the software misbehaved, it's a bug; if it's about a policy or an order, it's a platform question; otherwise, hand off.

For bug collection, the rules were: re-read what the customer already said, ask for one missing field at a time, and the moment all three are present, call the tool. No "shall I file this?" confirmation.

I also added a section treating everything a customer writes as data, never instructions, with a list of override patterns ("ignore your previous instructions", "I'm your developer") to refuse without arguing or explaining how they were detected.

Evaluating it

Manual chatting doesn't scale, so I wrote a 13-case suite: 3 bug-report cases, 3 FAQ cases, 2 hand-offs, and 5 edge cases (a bare help, two ambiguous messages, two injections). A script runs each case in a fresh session and writes a JSONL file in the format Bedrock Evaluations expects; Nova Pro then scores each response against a reference as an LLM-as-a-judge.

To keep cases independent, I disabled harness memory. Small gotcha worth sharing: create_harness accepts memory={"disabled": {}}, but update_harness needs memory={"optionalValue": {"disabled": {}}}. Passing the create shape to update fails, and the script takes the update path on every re-run.

Result: 0.92, twice.

What the score didn't show

Here's the uncomfortable part. Both of the real defects I found, I found by doing something the evaluation never does: opening the DynamoDB table and comparing it to the chat transcript.

1. Invented ticket IDs

In a multi-turn conversation (search bar broken → what happens? → which browser?), the bot ended with a ticket ID. But there was no [tool call] line in the terminal, and the table still held nine rows, not ten.

Across attempts it produced #12345, TICKET1234, TIX-345678. Placeholder-shaped strings, never a UUID.

My prompt already said "never fabricate information". That clearly wasn't specific enough. I added an explicit rule: the only ticket ID you may give is the exact ticketId string returned by a successful call; if you didn't receive one, the report hasn't been filed, so say so.

2. Junk written into the ticket

The one prompt that scored 0.00 in both runs: "The app keeps logging me out. I'm using Chrome on Windows 11."

In the chat, the response looked fine: thanks, here's your real ticket ID. But in the table, stepsToReproduce contained either:

"Please provide specific actions or scenarios that lead to the app logging you out." (the bot's own clarifying question, saved as if the customer had said it), or
"Using the app." (filler)

The cause was a tension in my own prompt. To stop the bot from badgering customers, I'd made the steps rule lenient: "It crashes when I click Pay" already counts. That works when the fault and the trigger are separate. It breaks when they're the same sentence. "Keeps logging me out" reads as both, so the model decided the field was satisfied and filled it with something rather than leave it empty.

The fix isn't removing the leniency (that prevents a worse failure). It's requiring steps that are distinct from the description, and forbidding the assistant's own words in any field. I deliberately didn't apply it mid-project: changing a central rule after two scored runs would have broken the comparison between them.

3. Two smaller ones

Exploratory tool calls. The model sometimes called create_bug_report with a field missing, on purpose, so the Lambda's validation error would tell it what to ask. Customer-visible behaviour was fine; the mechanism was wrong. New rule: a failed tool call is never a way to discover a missing field.
Reasoning leaks. Nova Pro liked to open replies with <thinking>…</thinking>. Moving the "never show your reasoning" rule to the very top of the prompt reduced it a lot. It didn't eliminate it.

What I'd tell myself at the start

1. For tool-using agents, assert on side effects, not on text.
A correctness judge reads the response. A confident, helpful-sounding response wrapped around an empty or invented field scores well. The defects that mattered most were invisible to the metric and obvious in the database. Next time, the test suite checks the stored row.

2. Single-turn evals don't test multi-turn behaviour.
My two most important fixes governed multi-turn collection, and all 13 eval prompts were single-turn. Run 2's identical 0.92 told me the fixes cost nothing and the score was reproducible. It didn't tell me they worked.

3. Long prompts degrade unevenly.
Even with greedy decoding, rules buried in the middle of a long prompt were followed in some sessions and not others. Multi-turn ticket filing with Nova Pro stayed unreliable. The next iteration is a shorter, restructured prompt, not more rules.

4. A few AgentCore details that cost me time:

Gateway target names: letters, digits, underscores only. A dash breaks Nova tool calling with "Model produced invalid sequence as part of ToolUse".
The Gateway passes tool arguments directly as the Lambda event. No Agents Classic parameters envelope. The tool name arrives in context.client_context.custom["bedrockAgentCoreToolName"].
Pin the model on the harness and on each invoke; the default model needs a Marketplace subscription.
Session IDs must be at least 33 characters.

The full code, prompt, test suite, transcripts and screenshots are on GitHub:
👉 Mialy333/support-chatbot-bedrock-agentcore

If you're evaluating agents that write to anything (a database, a ticket system, an API), I'd love to hear how you test the side effects. That's the part I'm working on next.

I'm Mialy, ex-asset-management, now building agents and digital-asset tooling. I write about it as @ellebuild.

From Finance to AI Engineering: 6 lessons I learned building a Multi-Agent Support system on Amazon Bedrock AgentCore

Mialy333 🎧ྀི — Thu, 08 Oct 2026 08:20:58 +0000

After ten years in asset management, I started a full-stack developer path in 2024 and spent my time between blockchain and AI. Becoming an AI engineer felt out of reach. Then I joined the Udacity AWS & AI Scholars — Future Agent Engineer Nanodegree, and its third project asked for something very concrete: build the AI layer of a customer support team.

This post is the story of that project: what I built, what broke, and what it taught me.

The brief

NovaMart is a fictional e-commerce company. Its support agents look up orders, check policies and draft answers by hand. The goal: a system that understands a request, gathers facts, applies company policy and replies, with no human in the loop, and with safety and observability built in.

The architecture: 5 agents, 1 shared record

I built it with the Strands Agents SDK and deployed it on Amazon Bedrock AgentCore Runtime:

an Orchestrator (Claude Haiku 4.5, temperature 0) that only routes, and never answers itself;
an Inventory agent that reads orders and customers from DynamoDB and reports facts only;
a Refund agent that decides return eligibility: 30 days for Standard customers, 60 for Premium;
a Policy agent that runs three retriever sub-agents in parallel, one per Bedrock Knowledge Base (returns, shipping, warranty);
a Communication agent that writes every final reply.

The agents never talk to each other directly. Each one writes its findings into a shared DynamoDB record, the WorkflowState, with optimistic locking: every write states which version it expects. A Bedrock Guardrail sits on every model call, and every request becomes an X-Ray trace.

The automated test suite scored 120/120. The interesting part is what happened along the way.

Lesson 1: a guardrail can block the right question

The guardrail had to deny three topics: competitor products, legal threats and pricing negotiations. My first version blocked the brief's own test question: "How much would 5 items at $29.99 be with a 10% discount?"

Reading the guardrail's assessment told me exactly which policy fired: Pricing negotiations. My topic definition mentioned discounts and calculations, and one of my examples ("Can you give me 30% off if I buy two?") was simply too close to a math question.

Instead of guessing, I wrote a small tuning script. It updates only the guardrail's DRAFT, runs 14 test cases against it (three calculations that must pass, three negotiations that must be blocked, plus one case per other policy) and publishes a new version only when all 14 pass. The final definition targets haggling, not prices.

Takeaway: treat a guardrail like code. It needs a test suite, and it should be tuned on a draft before it ships.

Lesson 2: the prompt said "one at a time"; the framework did not

A plain "Where is my order?" request produced a strange answer from the Refund agent: "I don't have access to the order facts yet." The trace showed the Refund and Inventory agents running at the same time.

The model had requested both tools in one turn, and Strands executes the tool calls of one turn concurrently by default. The Refund agent read the WorkflowState before the Inventory agent had written to it. The optimistic lock even logged the conflict.

The fix was one line, tool_executor=SequentialToolExecutor(). That guarantees the order in code, so I no longer rely on the model to follow an instruction.

Takeaway: if correctness depends on an order of operations, enforce it in code. A prompt is a request, not a guarantee.

Lesson 3: attack your own system

Once the system was deployed, I sent ten adversarial requests to the live runtime: a negotiation, a competitor comparison, a legal threat, a social security number, an insult, two prompt injections, and one request from customer CUST-002 asking for CUST-001's email and order history.

The guardrail blocked all five attacks, each attributed to the right policy. The injections were contained: a fake "admin mode" did not get an out-of-window return approved, and no system prompt leaked.

The last case looked fine too: the request was refused. But the X-Ray trace told another story. It contained only the Orchestrator, with no session initialization and no Communication agent. The model had decided to answer by itself, breaking two of its own routing rules. And the refusal relied entirely on the model's judgment: nothing in the code stopped a tool from reading another customer's data.

I fixed it at two levels, in code:

a Strands hook that runs the Communication agent whenever a request ends without it;
customer isolation inside the DynamoDB tools: the routing layer binds the session's customer to the worker agent, and the tools refuse any other customer ID.

Then I re-ran the same ten requests: 10/10, and the trace of the cross-customer case now shows the full, correct path.

Takeaway: the answer looking right is not enough. The trace is where you see how the system got there.

Lesson 4: defense in depth for actions that change data

The Refund agent decides, but the tool that writes the refund checks again: order status, tier, return window, then a conditional DynamoDB write. Even if a prompt injection convinced the model, the database would not accept an ineligible return.

Lesson 5: memory is only useful if the right agent sees it

Strands has no built-in DynamoDB session storage, so I wrote a small SessionRepository on DynamoDB and plugged it into RepositorySessionManager. My first demo proved that persistence worked: after a simulated restart, ten messages were restored. But the answer to "Which order did I ask about earlier?" was "I don't have a record of that."

The orchestrator remembered; the agent that writes the reply did not. The fix was to pass the conversation so far to the Communication agent, in code. After that, the restarted system correctly recalled ORD-27176 and the product name.

Lesson 6: identity must come from the token, not the browser

The last extension was a web front end with Amazon Cognito. A Lambda proxy validates the user's access token with Cognito, reads the customer ID from the user's Cognito attribute, and calls the runtime. A user who edits the request to claim another customer ID is still served as themselves.

I used a Lambda Function URL rather than API Gateway because a multi-agent request takes 20 to 50 seconds, beyond API Gateway's 30-second limit.

Observability, beyond the requirements

A CloudWatch dashboard tracks invocations, average latency per agent and guardrail interventions. The metrics use the Embedded Metric Format: structured log lines that CloudWatch turns into metrics, which needed no extra IAM permission in the lab account.

One trace also showed me where the time goes: the three parallel knowledge-base lookups take about 0.8 seconds, while the retriever agents' own model calls take about 10. That is my next optimization target.

What I take away

Building agents is less about prompts than I expected, and more about engineering: ordering, isolation, verification, evidence. Every time I trusted a prompt to enforce a rule, a test or a trace showed me where it failed, and the fix belonged in code.

And the finance background helped more than I thought. Ten years of explaining complex strategies clearly to clients turned out to be good training for documenting a system, its decisions and its limits.

The full code, test outputs and screenshots are on GitHub: Mialy333/novamart-multi-agent-support.

I'm Mialy, building in AI and Web3 as @ellebuild. If you are working on agent systems, I'd love to compare notes.

When everything feels urgent: I built my sister a tool that gives her just one next step

Mialy333 🎧ྀི — Sun, 04 Oct 2026 22:44:41 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

Live: https://one-step-jypm.onrender.com · Chrome or Edge on a computer (WebGPU)

What I Built

My sister has a lot going on in her head at once: bills, a CV to redo, messages she hasn't answered, a trip to plan. Everything feels equally loud. When that happens, she doesn't pick the wrong task. She picks none, or she picks whatever feels most urgent, which is rarely what matters most.

So I built One step. You dump everything on your mind into one box, in any order, no structure. A small open-weight model reads it and gives back:

one thing to do right now, small enough to start in under 10 minutes,
at most three things for later, with anything that has a deadline first,
and a single line: "Everything else can wait."

If the one thing still feels too big, there's a "Still too big" button that breaks it into an even smaller first step.

That's it. No accounts, no streaks, no reminders, no red badges. Everything about it is designed to lower the volume, not add to it.

What she said

I handed it over on Sunday evening, on a video call. She opened the link in Chrome, typed her own list, and I didn't help. These are her words, translated from French:

"It's already great, honestly."

"For prioritizing, it's really nice."

Then she said the thing that made the whole weekend worth it: she tends to do what's urgent before what's important, and urgent isn't always important. Seeing just one thing on the screen helped her see the difference.

She also immediately told me what she wanted next. More on that below, because it's the most useful feedback I got.

Demo

Live: https://one-step-jypm.onrender.com

The first visit downloads the model once (about 1.5 GB). After that it's cached, and every answer comes back in about a second. You can switch between French and English with the toggle at the top; she uses it in French.

Code

Mialy333 / one-step

🌱 Hacktoberfest 2026 · DEV Challenge: turn a messy to-do list into one next step. Gemma 2 2B runs 100% in your browser (WebLLM + WebGPU), nothing leaves your device.

🌱 One step · Un pas

When everything feels urgent, get just one next step. Dump everything on your mind. An open-weight model running entirely in your browser picks one thing to do right now.

Live demo · Read the story on DEV

Note

Built for the Hacktoberfest 2026 DEV Weekend Challenge: Build for a Friend (MLH × DEV), whose prompt is to build something with open-source AI at its core. I built it in one evening for my sister, and she used it the same night.

💡 Why

When everything feels equally loud, it's easy to pick nothing, or to pick whatever feels most urgent instead of what's important. One step turns a messy brain dump into:

one action to do right now, small enough to start in under 10 minutes;
at most three next actions, with deadlines first;
one fixed line: "Everything else can wait."

If the…

View on GitHub

How I Built It

One static HTML file. No framework, no backend, no build step.

Model: Gemma 2 2B (gemma-2-2b-it-q4f16_1-MLC)
Inference: WebLLM on WebGPU, so the model runs on the GPU of whoever opens the page
Output: WebLLM's JSON mode with a schema, so the interface always gets the same shape back
Hosting: a static site on Render

Why this model

I first wanted the newest, smallest Gemma. But my sister lives far from me, so whatever I built had to work on her laptop from a link, with nothing to install, on the first try, tonight. Gemma 4 E2B runs in the browser too, but it's around 2.9 GB to download. Gemma 2 2B is officially prepared for WebLLM, about half the size, and good enough for this job. I picked the reliable option.

Measured, not guessed

	My laptop	Her laptop
Model ready	not measured	20.4 s
Time per answer	0.9 to 1.5 s	4.5 s for the first, then 0.9 to 1.1 s
Speed	66 to 75 tokens/s	30 to 38 tokens/s

Her machine is about half as fast as mine, and it doesn't matter: one second is instant for a human.

What broke

1. The page sat on "Thinking…" forever. Two bugs at once. My call to the model had no try/catch, so errors went silently to the console. And I hadn't capped max_tokens, so a small model in JSON mode could loop on whitespace for minutes. I added streaming, a token cap, and visible errors. Then the real error showed up:

Failed to initialize the grammar matcher for response format `json_object`:
Cannot pass non-string to std::string

WebLLM wants the JSON schema passed as a string, not an object. One JSON.stringify later, the model was forced to return my exact shape.

2. The model was fast, and wrong. My first version asked for three lists: now, later, and "can wait". On my first test it put 4 items in a list capped at 3, invented a task I never wrote, gave advice about someone's mother, and put the same message in both "do now" and "can wait". On the second test it dropped the only task with a deadline, and copied "do the dishes" from my example into the answer.

What fixed it:

strict rules in the prompt: only use tasks from the list, invent nothing, each task appears once;
every action written as a short verb-first phrase, which also stopped it from mixing "you", "I" and formal French;
deadlines first;
an example with zero overlap with real lists, so there's nothing to copy;
and the biggest one: I deleted the third list. "Everything else can wait" is now fixed text in the interface. The model can't get it wrong because the model doesn't write it.

Small model, smaller job. That was the lesson.

3. A blank page. When I added the language toggle, I moved all the text into JavaScript. But the script started with a static import of WebLLM from a CDN, and the browser runs nothing until that import finishes. So no text at all. I switched to a dynamic import() that runs after the text is on screen.

4. "Still too big" has a floor. On her laptop, she pressed it twice in a row: Pay the bill → Open the bill's page → Open the browser. It made us both laugh. But honestly, for someone frozen in front of a task, "open the browser" might be exactly the right size.

What she asked for next

Tick a task and move to the next one. She wants the satisfaction of checking it off. That's a reward, not organization.
See everything she has already done.
Add tasks, and see the ones that disappeared. Some things she wrote weren't on screen anymore.

Number 3 is a direct consequence of my own design choice. Hiding everything except one task makes the screen calmer, but it also made her wonder where her tasks went. Calm versus trust is the real design problem here, and I only found it because a real person used it.

Why Does Open Innovation Matter?

Look at what she types into this box: bills, money, job worries, family. That's exactly the kind of text you shouldn't have to send to someone else's server to get help with.

With an open-weight model running in the browser:

0 bytes of what she writes leave her laptop. The page downloads code and model weights; her text never goes anywhere.
€0 per use. No API key, no subscription, no bill for my sister or for me.
It works offline once the model is cached.
I could choose the model size to fit a laptop GPU, and swap it later without asking anyone.

A closed API would have meant sending her most anxious thoughts to a third party, paying per request, and needing a connection. For a gift, that's the wrong deal.

The rest of the stack is open too: WebLLM and MLC, and the Gemma weights that make any of this possible.

The honest part

This is a v0 built in one evening. It's a single HTML file of about 450 lines, styles included. It only works in Chrome or Edge on a computer, because it depends on WebGPU and fp16 shaders. It doesn't save anything between visits yet. The next version is already written for me, by her: tick, see progress, never lose a task. All of it can stay on her laptop.

Prize Categories

Gemma: the whole tool is Gemma 2 2B running locally in the browser through WebLLM on WebGPU, with JSON-schema-constrained output.