However, I don't think having an agent on one side necessarily changes anything. Network problems are not predictable, particularly on mobile, so the human is still very likely to experience a poor auditory experience on a tcp connection.

Maybe it's a comprehension issue on my end, but he seems to associate things like stun and dtls as related, compounding issues (particularly in round trip time), but they are really orthogonal.

Also, he spends too much time talking about how you can't resend packets, and reiterates that point by stating they tried really hard (at discord?). That's where he lost the plot, imo.

The RTC in WebRTC is about real time communication. Humans will naturally prefer the auditory experience of an occasional dropped packet, vs backed up audio or audio that plays at an uneven rate. To clarify, I'm talking about human speech here.

If you want to tolerate packet loss, use a protocol based on tcp instead of udp. But you know what happens when you send audio over poor network conditions with tcp? There will be pauses on the receiving end as it waits for the next correct packet. Let's say the delay is multiple seconds. What should the receiving end do when packets start flowing again? Plays the clogged audio at a natural clock? Attempt to play the audio back at a higher rate to "catch up" with any other channels? People, humans, do not generally prefer that experience.

Forget about WebRTC for a minute, but instead think about tcp vs udp for voice. Voip has been based on udp since the 90's for a reason.

I will still reach for a database 99% or the time, because I like things like SQL and transactions. However, I've recently been working on a 100% personal project to manage some private data; extracting insights, graphing trends, etc. It's not high volume data, so I decided to use just the file system, with data backed at yaml files, with some simple indexing, and I haven't run into any performance issues yet. I probably never will at my scale and volume.

In this particular case having something that was human readable, and more importantly diffable, was more valuable to me than outright performance.

Having said that, I will still gladly reach for a database with a query language and all the guarantees that comes with 99% of the time.

Some of us need assistance to communicate effectively. And for me, yes that took 3 hours even with this assistance.

I didn't actually create my account until 2021? 2022? I can't remember. And I didn't make my first post or even comment until just last week.

While I think a minimum post count or reputation metric could perhaps reduce the AI generated posts, introducing friction also makes it harder for real people to contribute anything meaningful.

Furthermore, what does it matter if it's "AI generated"? Is some AI content ok? What's the pass/fail threshold on human vs AI generated text?

I made a Show post last week where I heavily relied on AI. I'm sure there are some "tells." But even so, I spent more than three hours working on the content of my post and my first response. Would my post have been acceptable to you?

If you want to dig deeper on the architecture, I wrote up the dual-LLM design and the memory system on my engineering blog:

- https://www.conecrows.com/blog/augur-soft-launch — covers the dual-LLM turn loop, perception gating, and why the single-LLM approach failed - https://www.conecrows.com/blog/augur-memory-v1 — covers impression extraction, vector embeddings, and lossy synthesis

The stack is Fastify, Next.js, Supabase (Postgres + Auth), and both OpenAI and Anthropic models for the engine and analysis. Encounters cost roughly $0.08–$0.15 per turn (internal cost) depending on state complexity and encounter length.

The core idea is simple: you play a text-based boss encounter against a character called the Architect, set in a strange library. You can fight, sneak, persuade, or try something I haven't thought of. Turns are mechanically resolved with d100 rolls, conditions track injuries instead of HP, and objects in the world have physical properties the LLM reasons about. The "engine" is property-based instead of tables of rules, and I've found that to yield some novel gameplay.

The part I'm most interested in exploring is the learning. The Architect builds impressions from what it actually perceived during an encounter, stores them as vector embeddings, and retrieves relevant ones at the start of future encounters. It's lossy on purpose — more like human memory than a database lookup. If a tactic keeps working, the Architect starts recognizing the pattern. If you sneak past undetected, it remembers losing but not how.

The technical foundation for all of this is a dual-LLM turn loop. Each turn makes two model calls: an engine model that sees full game state and resolves mechanics, then an architect model that only receives what it has actually perceived (line of sight, noise, zone proximity). The "information asymmetry" is structural and deliberate — the architect model literally cannot access state the engine doesn't pass through the perception filter.

I tried the single-LLM approach first and it didn't work. No matter how carefully you prompt a model to "forget" information sitting in its context window, it leaks. Not to mention the Architect had the habit of adopting God Mode. So splitting the roles made the whole thing feel honest in a way prompt engineering alone couldn't.

This is my first HN post, and this is a real launch on modest infrastructure (single Fly.io instance, small Supabase project), so if it gets any traffic I might hit some rough edges. There's a free trial funded by a community pool, or you can grab credits for $5/$10 if you want to keep going. It's best experienced in a full desktop browser, but it's passable on the two mobile devices I've tested it on.

Playable here: https://www.theaugur.ai/

I'm happy to go deeper on any of the internals — turn flow, perception gating, memory extraction, cost model, whatever is interesting.

Comments URL: https://news.ycombinator.com/item?id=47241749

Points: 3

# Comments: 1