Ask HN: Building LLM apps? How are you handling user context?
10 by marcospassos | 2 comments on Hacker News.
I've been building stuff with LLMs, and every time I need user context, I end up manually wiring up a context pipeline. Sure, the model can reason and answer questions well, but it has zero idea who the user is, where they came from, or what they've been doing in the app. Without that, I either have to make the model ask awkward initial questions to figure it out or let it guess, which is usually wrong. So I keep rebuilding the same setup: tracking events, enriching sessions, summarizing behavior, and injecting that into prompts. It makes the app way more helpful, but it's a pain. What I wish existed is a simple way to grab a session summary or user context I could just drop into a prompt. Something like: const context = await getContext(); const response = await generateText({ system: `Here's the user context: ${context}`, messages: [...]}); Some examples of how I use this: - For support, I pass in the docs they viewed or the error page they landed on. - For marketing, I summarize their journey, like 'ad clicked' → 'blog post read' → 'pricing page'. - For sales, I highlight behavior that suggests whether they're a startup or an enterprise. - For product, I classify the session as 'confused', 'exploring plans', or 'ready to buy'. - For recommendations, I generate embeddings from recent activity and use that to match content or products more accurately. In all of these cases, I usually inject things like recent activity, timezone, currency, traffic source, and any signals I can gather that help guide the experience. Has anyone else run into this same issue? Found a better way? I'm considering building something around this initially to solve my problem. I'd love to hear how others are handling it or if this sounds useful to you.
10 by marcospassos | 2 comments on Hacker News.
I've been building stuff with LLMs, and every time I need user context, I end up manually wiring up a context pipeline. Sure, the model can reason and answer questions well, but it has zero idea who the user is, where they came from, or what they've been doing in the app. Without that, I either have to make the model ask awkward initial questions to figure it out or let it guess, which is usually wrong. So I keep rebuilding the same setup: tracking events, enriching sessions, summarizing behavior, and injecting that into prompts. It makes the app way more helpful, but it's a pain. What I wish existed is a simple way to grab a session summary or user context I could just drop into a prompt. Something like: const context = await getContext(); const response = await generateText({ system: `Here's the user context: ${context}`, messages: [...]}); Some examples of how I use this: - For support, I pass in the docs they viewed or the error page they landed on. - For marketing, I summarize their journey, like 'ad clicked' → 'blog post read' → 'pricing page'. - For sales, I highlight behavior that suggests whether they're a startup or an enterprise. - For product, I classify the session as 'confused', 'exploring plans', or 'ready to buy'. - For recommendations, I generate embeddings from recent activity and use that to match content or products more accurately. In all of these cases, I usually inject things like recent activity, timezone, currency, traffic source, and any signals I can gather that help guide the experience. Has anyone else run into this same issue? Found a better way? I'm considering building something around this initially to solve my problem. I'd love to hear how others are handling it or if this sounds useful to you.
Launch HN: Nomi (YC X25) – Cursor for Sales
4 by ethansafar | 0 comments on Hacker News.
Hey HN, we’re Swan and Ethan, and we’re building https://heynomi.com , a real-time AI that helps you sell better while you're actually in the call.Demo: https://youtu.be/XFxDCP8jdY8?si=CGnPM1zT4wxAvadJ Most of us aren’t trained in sales. We weren’t either. But in the early days, it’s the founders who have to sell, and learning that on live calls is brutal. After one particularly painful deal we lost, we joked that we needed an AI cofounder who could talk in our ear and save us from ourselves. That joke turned into a prototype, then a product. Nomi joins your video calls and gives you phrase suggestions when it matters most:– when someone pushes back,– when there’s a hidden signal worth digging into,– when it’s time to close (and how to do it without sounding pushy). Then after the call, it auto-generates clean CRM notes, action items, and sends you a short email breaking down what went well, what didn’t, and how to improve next time—based on your actual conversation. We’re also rolling out some features to make every call a learning opportunity and unlock revenue potential:– A/B testing different sets of objections during calls and comparing results in real time– Auto-update of your company’s sales playbook based on what’s actually working– Upsell opportunity spotting and predictive revenue estimates driven by what people say on calls The real-time part was the hardest. If advice shows up 2 seconds late, or it's off-topic, it's worse than useless. So we built a system with:- a Thinking Model to track the call’s momentum;- a tactic selector trained with reinforcement learning;- a lightweight LLM (boosted with RAG) that delivers custom phrase suggestions under 500 ms. Each user gets a private copilot trained on their own calls (with permission), plus simulated data and sales best practices. It gets sharper with every interaction, no manual tuning needed. Right now, we’re live with 30 teams. One company went from $200K to $360K in just a few weeks. Another brought on a new rep who closed their first deal with Nomi on week one. We also offer a free AI note-taker and free sales-coaching post-call emails. Just shoot us an email if you want to try it: founders@heynomi.com We’re launching on HN to meet other folks who’ve felt this pain, founders doing sales, builders figuring things out on the fly. If that’s you, we’d love your feedback. Or if you just want to geek out about fast-inference LLMs, streaming RAG, or real-time UX, happy to go deep. Let us know what you think!
4 by ethansafar | 0 comments on Hacker News.
Hey HN, we’re Swan and Ethan, and we’re building https://heynomi.com , a real-time AI that helps you sell better while you're actually in the call.Demo: https://youtu.be/XFxDCP8jdY8?si=CGnPM1zT4wxAvadJ Most of us aren’t trained in sales. We weren’t either. But in the early days, it’s the founders who have to sell, and learning that on live calls is brutal. After one particularly painful deal we lost, we joked that we needed an AI cofounder who could talk in our ear and save us from ourselves. That joke turned into a prototype, then a product. Nomi joins your video calls and gives you phrase suggestions when it matters most:– when someone pushes back,– when there’s a hidden signal worth digging into,– when it’s time to close (and how to do it without sounding pushy). Then after the call, it auto-generates clean CRM notes, action items, and sends you a short email breaking down what went well, what didn’t, and how to improve next time—based on your actual conversation. We’re also rolling out some features to make every call a learning opportunity and unlock revenue potential:– A/B testing different sets of objections during calls and comparing results in real time– Auto-update of your company’s sales playbook based on what’s actually working– Upsell opportunity spotting and predictive revenue estimates driven by what people say on calls The real-time part was the hardest. If advice shows up 2 seconds late, or it's off-topic, it's worse than useless. So we built a system with:- a Thinking Model to track the call’s momentum;- a tactic selector trained with reinforcement learning;- a lightweight LLM (boosted with RAG) that delivers custom phrase suggestions under 500 ms. Each user gets a private copilot trained on their own calls (with permission), plus simulated data and sales best practices. It gets sharper with every interaction, no manual tuning needed. Right now, we’re live with 30 teams. One company went from $200K to $360K in just a few weeks. Another brought on a new rep who closed their first deal with Nomi on week one. We also offer a free AI note-taker and free sales-coaching post-call emails. Just shoot us an email if you want to try it: founders@heynomi.com We’re launching on HN to meet other folks who’ve felt this pain, founders doing sales, builders figuring things out on the fly. If that’s you, we’d love your feedback. Or if you just want to geek out about fast-inference LLMs, streaming RAG, or real-time UX, happy to go deep. Let us know what you think!
WavePhoenix – open-source implementation of the Nintendo WaveBird protocol
11 by zdw | 0 comments on Hacker News.
11 by zdw | 0 comments on Hacker News.
Data breach exposes 184M passwords for Google,Microsoft,Facebook
20 by taubek | 3 comments on Hacker News.
20 by taubek | 3 comments on Hacker News.
Show HN: PgDog – Shard Postgres without extensions
14 by levkk | 0 comments on Hacker News.
Hey HN! Lev here, author of PgDog ( https://ift.tt/RAF80NK ). I’m scaling our favorite database, PostgreSQL. PgDog is a new open source proxy, written in Rust, with first-class support for sharding — without changes to your app or needing database extensions. Here’s a walkthrough of how it works: https://www.youtube.com/watch?v=y6sebczWZ-c Running Postgres at scale is hard. Eventually, one primary isn’t enough at which point you need to split it up. Since there is currently no good tooling out there to do this, teams end up breaking their apps apart instead. If you’re familiar with PgCat, my previous project, PgDog is its spiritual successor but with a fresh codebase and new goals. If not, PgCat is a pooler for Postgres also written in Rust. You guessed it — I adopted a dog. So, what’s changed and why a new project? Cross-shard queries are supported out of the box. The new architecture is more flexible, completely asynchronous and supports manipulating the Postgres protocol at any stage of query execution. Not everything is working, but simple aggregates like max(), min(), count(*) and sum() are in. More complex functions like percentiles and average will require a bit more work. Sorting (i.e. ORDER BY) works, as long as the values are part of the result set, e.g.: SELECT id, email FROM users WHERE admin = true ORDER BY 1 DESC; PgDog buffers and sorts the rows in memory, before sending them to the client. Most of the time, the working set is small, so this is fine. For larger results, we need to build swap to disk, just like Postgres does, but for OLTP workloads, which PgDog is targeting, we want to keep things fast. Sorting currently works for bigint, integer, and text/varchar. It’s pretty straightforward to add all the other data types, I just need to find the time and make sure to handle binary encoding correctly. All standard Postgres features work as normal for unsharded and direct-to-shard queries. As long as you include the sharding key (a column like customer_id, for example) in your query, you won’t notice a difference. How does this compare to Citus? In case you’re not familiar, Citus is an open source extension for sharding Postgres. It runs inside a single Postgres node (a coordinator) and distributes queries between worker databases. PgDog’s architecture is fundamentally different. It runs outside the DB: it’s a proxy, so you can deploy it anywhere, including managed Postgres like RDS, Cloud SQL and others where Citus isn’t available. It’s multi-threaded and asynchronous, so it can handle thousands, if not millions, of concurrent connections. Its focus is OLTP, not OLAP. Meanwhile, Citus is more mature and has good support for cross-shard queries and aggregates. It will take PgDog a while to catch up. My Rust has improved since my last attempt at this and I learned how to use the bytes crate correctly. PgDog does almost zero memory allocations per request. That results in a 3-5% performance increase over PgCat and a much more consistent p95. If you’re obsessed with performance like me, you know that small percentage is nothing to sneeze at. Like before, multi-threaded Tokio-powered PgDog leaves the single-threaded PgBouncer in the dust ( https://ift.tt/A8DPzdc ). Since we’re using pg_query (which itself bundles the Postgres parser), PgDog can understand all Postgres queries. This is important because we can not only correctly extract the WHERE clause and INSERT parameters for automatic routing, but also rewrite queries. This will be pretty useful when we’ll add support for more complex aggregates, like avg(), and cross-shard joins! Read/write traffic split is supported out of the box, so you can put PgDog in front of the whole cluster and ditch the code annotations. It’s also a load balancer, so you can deploy it in front of multiple replicas to get 4 9’s of uptime. One of the coolest features so far, in my opinion, is distributed COPY. This works by hacking the Postgres…
14 by levkk | 0 comments on Hacker News.
Hey HN! Lev here, author of PgDog ( https://ift.tt/RAF80NK ). I’m scaling our favorite database, PostgreSQL. PgDog is a new open source proxy, written in Rust, with first-class support for sharding — without changes to your app or needing database extensions. Here’s a walkthrough of how it works: https://www.youtube.com/watch?v=y6sebczWZ-c Running Postgres at scale is hard. Eventually, one primary isn’t enough at which point you need to split it up. Since there is currently no good tooling out there to do this, teams end up breaking their apps apart instead. If you’re familiar with PgCat, my previous project, PgDog is its spiritual successor but with a fresh codebase and new goals. If not, PgCat is a pooler for Postgres also written in Rust. You guessed it — I adopted a dog. So, what’s changed and why a new project? Cross-shard queries are supported out of the box. The new architecture is more flexible, completely asynchronous and supports manipulating the Postgres protocol at any stage of query execution. Not everything is working, but simple aggregates like max(), min(), count(*) and sum() are in. More complex functions like percentiles and average will require a bit more work. Sorting (i.e. ORDER BY) works, as long as the values are part of the result set, e.g.: SELECT id, email FROM users WHERE admin = true ORDER BY 1 DESC; PgDog buffers and sorts the rows in memory, before sending them to the client. Most of the time, the working set is small, so this is fine. For larger results, we need to build swap to disk, just like Postgres does, but for OLTP workloads, which PgDog is targeting, we want to keep things fast. Sorting currently works for bigint, integer, and text/varchar. It’s pretty straightforward to add all the other data types, I just need to find the time and make sure to handle binary encoding correctly. All standard Postgres features work as normal for unsharded and direct-to-shard queries. As long as you include the sharding key (a column like customer_id, for example) in your query, you won’t notice a difference. How does this compare to Citus? In case you’re not familiar, Citus is an open source extension for sharding Postgres. It runs inside a single Postgres node (a coordinator) and distributes queries between worker databases. PgDog’s architecture is fundamentally different. It runs outside the DB: it’s a proxy, so you can deploy it anywhere, including managed Postgres like RDS, Cloud SQL and others where Citus isn’t available. It’s multi-threaded and asynchronous, so it can handle thousands, if not millions, of concurrent connections. Its focus is OLTP, not OLAP. Meanwhile, Citus is more mature and has good support for cross-shard queries and aggregates. It will take PgDog a while to catch up. My Rust has improved since my last attempt at this and I learned how to use the bytes crate correctly. PgDog does almost zero memory allocations per request. That results in a 3-5% performance increase over PgCat and a much more consistent p95. If you’re obsessed with performance like me, you know that small percentage is nothing to sneeze at. Like before, multi-threaded Tokio-powered PgDog leaves the single-threaded PgBouncer in the dust ( https://ift.tt/A8DPzdc ). Since we’re using pg_query (which itself bundles the Postgres parser), PgDog can understand all Postgres queries. This is important because we can not only correctly extract the WHERE clause and INSERT parameters for automatic routing, but also rewrite queries. This will be pretty useful when we’ll add support for more complex aggregates, like avg(), and cross-shard joins! Read/write traffic split is supported out of the box, so you can put PgDog in front of the whole cluster and ditch the code annotations. It’s also a load balancer, so you can deploy it in front of multiple replicas to get 4 9’s of uptime. One of the coolest features so far, in my opinion, is distributed COPY. This works by hacking the Postgres…
TeleMessage Customers Include DC Police, Andreessen Horowitz, JP Morgan,Hundreds
41 by Bluestein | 0 comments on Hacker News.
41 by Bluestein | 0 comments on Hacker News.
Duolingo CEO tries to walk back AI-first comments, fails
18 by Improvement | 0 comments on Hacker News.
18 by Improvement | 0 comments on Hacker News.
Claude 4 and GitHub MCP will leak your private GitHub repositories
52 by amrrs | 6 comments on Hacker News.
52 by amrrs | 6 comments on Hacker News.