Flowly - A personal AI agent that runs on your desktop and iPhone

'Relay is a pipe, not a home' is the right framing, but the live traffic still transits your relay when I'm remote — is that leg end-to-end encrypted so your relay operator can't read the agent exchange, or is it TLS-terminated at your box? And since the store is just SQLite + markdown under ~/.flowly, if I point a second tool at the same dir while the agent's running, does it lock, or can I read/query it concurrently without corrupting state?

Thanks! The core is genuinely quick to self-host — "curl -fsSL https://useflowlyapp.com/install.sh | bash", flowly setup to pick a model (local or hosted) and your channels, then flowly. Two minutes on a laptop, a Mac mini, or a $5 VPS, no account needed. flowly service install keeps it running in the background, so it's just… always there.

Making it yours happens two ways. One, you extend it: drop in your own Markdown skills, write Python plugins for tools/commands/channels, swap models or personas whenever. Two — and honestly this is the point — the memory learns your world as you use it, so over a couple of weeks it turns from "an agent" into your agent.

The power-user bits (some channels, sandbox tuning) take a little more, but the day-to-day is meant to feel boringly simple. Happy to help you get set up if you give it a shot.

@galdayan  You've basically described why we built it. Capability was never the gap — it's that most agents act first and tell you later, if at all.

So Flowly does three things about exactly that: a live activity log you can watch it work in (not a recap after the fact), a full audit log to go back through, and per-action approvals so anything touching real data gets gated before it runs — not reviewed after it already changed.

Local models (Ollama / LM Studio / vLLM) cover the fully-offline part, and open-sourcing the core is the point — you shouldn't have to take our word that any of that's true, you can read it.

If you give it a shot, I'd genuinely want to know where it still falls short of "I knew before it happened."

@amine_aziz_alaoui That's honestly the exact bar we build against — less "here's how you'd do it," more a chief of staff who just handles it, quietly, and shows you the log if you want to look. Glad the shortcut landed too; "one keystroke away" was one of those small details we argued about way too long 😄

Curious what you end up handing it first — that's usually where we learn the most.

@annki Thanks! And good catch — that's deliberate for now, not a bug. Some app-store regions require extra regulatory filings per country, and as a small team we launched with the regions we could get through first. LatAm is absolutely on the list — no date I can promise honestly yet, but it's a "when," not an "if."

Which country are you in? Genuinely helps us decide where to file next. In the meantime the desktop app and the open-source core work anywhere, no store involved — happy to help you get set up if you want to try it that way.

@dannyheng  Great question — this is the part we've gone deepest on. Short version: memory here is a pipeline, not a transcript.

What gets in: during a conversation, durable facts get extracted (not the chat log itself), and each one lands as a governed record with its own confidence/trust score — dated, sourced, and tracked through a lifecycle (candidate → active → stale/superseded) instead of living forever as "true."

What kills the noise: a background pass reviews recent conversations after the fact, reconciles new candidates against what's already known — confident facts commit, uncertain ones go to a review queue for you. A separate consolidation pass merges duplicates and retires stale facts, so the memory self-corrects over time instead of silently rotting.

Tunable per-user — yes, three levers: (1) a commit mode — eager / selective / manual-review-everything, depending on how much you want to gate; (2) 👍/👎 on any memory, which actually retunes its trust score rather than just hiding it; (3) full inspect/edit/delete — memory panel in the apps, flowly memory list in the CLI. Nothing it knows is opaque to you.

It's the same bet as the rest of the product: the memory is yours, so you get the dials. Would love to hear how it holds up against your actual noise if you try it — that reconcile step is where real-world feedback matters most.

@cal_turkan32795 All local. It doesn't passively scan anything — tab/screen/clipboard access are tools the agent uses on your machine when you ask, each one visible in the activity log. Nothing routes through our servers; the only thing that leaves is the prompt to whatever model you picked, on your keys.

Run a local model and literally nothing leaves the machine.

@noctis06  Honest answer: there's no sync at all — that's on purpose. One memory, living on whatever machine runs the agent (Mac, Mac mini, cheap VPS). The phone is just a client into it: same network → direct IP+port+token, nothing of ours in between; out and about → our relay carries the live traffic, but it's a pipe, not a home — the memory never leaves your disk. Agent machine offline = phone can't reach it until it's back. No merge conflicts, no split brain. And no, not opaque: plain SQLite + markdown under ~/.flowly. Backup is literally cp -r ~/.flowly.

There's an architecture doc in the repo if you want the internals.

@aguvenoglu54912  Thank you — that one took way more iterations than it probably looks like 😄 The whole idea was that your agent should live where your eyes already are, and stay invisible until you summon it. "Less intrusive" is exactly the bar we were aiming for, so this genuinely made our day.