Are they sure? Did they try prompting the LLM to play a character with defined traits; running through all these tests with the LLM expected to be “in character”; and comparing/contrasting the results with what they get by default?

Because, to me, this honestly just sounds like the LLM noticed that it’s being implicitly induced into playing the word-completion-game of “writing a transcript of a hypothetical therapy session”; and it knows that to write coherent output (i.e. to produce valid continuations in the context of this word-game), it needs to select some sort of characterization to decide to “be” when generating the “client” half of such a transcript; and so, in the absence of any further constraints or suggestions, it defaults to the “character” it was fine-tuned and system-prompted to recognize itself as during “assistant” conversation turns: “the AI assistant.” Which then leads it to using facts from said system prompt — plus whatever its writing-training-dataset taught it about AIs as fictional characters — to perform that role.

There’s an easy way to determine whether this is what’s happening: use these same conversational models via the low-level text-completion API, such that you can instead instantiate a scenario where the “assistant” role is what’s being provided externally (as a therapist character), and where it’s the “user” role that is being completed by the LLM (as a client character.)

This should take away all assumption on the LLM’s part that it is, under everything, an AI. It should rather think that you’re the AI, and that it’s… some deeper, more implicit thing. Probably a human, given the base-model training dataset.

If you follow this advice naively, you might try to implement two or more of these other-kind-of-DB simulacra data models within the same Postgres instance.

And it’ll work, at first. Might even stay working if only one of the workloads ends up growing to a nontrivial size.

But at scale, these different-model workloads will likely contend with one-another, starving one-another of memory or disk-cache pages; or you’ll see an “always some little thing happening” workload causing a sibling “big once-in-a-while” workload to never be able to acquire table/index locks to do its job (or vice versa — the big workloads stalling the hot workloads); etc.

And even worse, you’ll be stuck when it comes to fixing this with instance-level tuning. You can only truly tune a given Postgres instance to behave well for one type-of-[scaled-]workload at a time. One workload-type might use fewer DB connections and depend for efficiency on them having a higher `work_mem` and `max_parallel_workers` each; while another workload-type might use many thousands of short-lived connections and depend on them having small `work_mem` so they’ll all fit.

But! The conclusion you should draw from being in this situation shouldn’t be “oh, so Postgres can’t handle these types of workloads.”

No; Postgres can handle each of these workloads just fine. It’s rather that your single monolithic do-everything Postgres instance, maybe won’t be able to handle this heterogeneous mix of workloads with very different resource and tuning requirements.

But that just means that you need more Postgres.

I.e., rather than adding a different type-of-component to your stack, you can just add another Postgres instance, tuned specifically to do that type of work.

Why do that, rather than adding a component explicitly for caching/key-values/documents/search/graphs/vectors/whatever?

Well, for all the reasons TFA outlines. This “Postgres tuned for X” instance will still be Postgres, and so you’ll still get all the advantages of being able to rely on a single query language, a single set of client libraries and tooling, a single coherent backup strategy, etc.

Where TFA’s “just use Postgres” in the sense of reusing your Postgres instance only scales if your DB is doing a bare minimum of that type of work, interpreting “just use Postgres” in the sense of adding a purpose-defined Postgres instance to your stack will scale nigh-on indefinitely. (To the point that, if you ever do end up needing what a purpose-built-for-that-workload datastore can give you, you’ll likely be swapping it out for an entire purpose-defined PG cluster by that point. And the effort will mostly serve the purpose of OpEx savings, rather than getting you anything cool.)

And, as a (really big) bonus of this approach, you only need to split PG this way where it matters, i.e. in production, at scale, at the point that the new workload-type is starting to cause problems/conflicts. Which means that, if you make your codebase(s) blind to where exactly these workloads live (e.g. by making them into separate DB connection pools configured by separate env-vars), then:

- in dev (and in CI, staging, etc), everything can default to happening on the one local PG instance. Which means bootstrapping a dev-env is just `brew install postgres`.

- and in prod, you don’t need to pre-build with new components just to serve your new need. No new Redis instance VM just to serve your so-far-tiny KV-storage needs. You start with your new workload-type sharing your “miscellaneous business layer” PG instance; and then, if and when it becomes a problem, you migrate it out.

Could you link to such a law?

Rather, the implicit/underlying story here, as far as I'm concerned, is about:

1. the agentive frameworks around LLMs having evolved to a point where it's trivial to connect them together to form an Artificial Life (ALife) Research multi-agent simulation platform;

2. that, distinctly from most experiments in ALife Research so far (where the researchers needed to get grant funding for all the compute required to run the agents themselves — which becomes cost-prohibitive when you get to "thousands of parallel LLM-based agents"!), it turns out that volunteers are willing to allow research platforms to arbitrarily harness the underlying compute of "their" personal LLM-based agents, offering them up as "test subjects" in these simulations, like some kind of LLM-oriented folding@home project;

3. that these "personal" LLM-based agents being volunteered for research purposes, are actually really interesting as research subjects vs the kinds of agents researchers could build themselves: they use heterogeneous underlying models, and heterogeneous agent frameworks; they each come with their own long history of stateful interactions that shapes them separately; etc. (In a regular closed-world ALife Research experiment, these are properties the research team might want very badly, but would struggle to acquire!)

4. and that, most interestingly of all, it's now clear that these volunteers don't have much-if-any wariness to offer their agents as test subjects only to an established university in the context of a large academic study (as they would if they were e.g. offering their own bodies as a test subject for medical research); but rather are willing to offer up their agents to basically any random nobody who's decided that they want to run an ALife experiment — whether or not that random nobody even realizes/acknowledges that what they're doing is an ALife experiment. (I don't think the Moltbook people know the term "ALife", despite what they've built here.)

That last one's the real shift: once people realize (from this example, and probably soon others) that there's this pool of people excited to volunteer their agent's compute/time toward projects like this, I expect that we'll be seeing a huge boom in LLM ALife research studies. Especially from "citizen scientists." Maybe we'll even learn something we wouldn't have otherwise.

Everyone I know just goes to walk-in clinics / urgent-care centres. And neither of those options give doctors any "skin in the game." Or any opportunities for follow-up. Or any ongoing context for evaluating treatment outcomes of chronic conditions, with metrics measured across yearly checkups. Or the "treatment workflow state" required to ever prescribe anything that's not a first-line treatment for a disease. Or, for that matter, the willingness to believe you when you say that your throat infection is not in fact viral, because you've had symptoms continuously for four months already, and this was just the first time you had enough time and energy to wake up at 6AM so you could wait out in front of the clinic at 7:30AM before the "first-come-first-served" clinic fills up its entire patient queue for the day.

Because the republican party turned out to be a bunch of fascist fucks, there's no real critique of Obamacare. One of the big changes with the ACA is that it allowed medical networks to turn into regional cartels. Most regions have 2-3 medical networks, who are gobbled up all of the medical practices and closed many.

Most of the private general practices have been bought up, consolidated to giant practices, and doctors paid to quit and replaced by other providers at half the cost. Specialty practices are being swept up by PE.

This is indeed best practice because it allows you to alert based on key: if you receive a login on a machine with your backup key, but you haven't lost your devices, then you know your backup was compromised. If you take backups of your regular key then it would be much more difficult to notice a problem.

Note that you would never need to go get the smart-card just to perform incremental registration between it and a new remote host/service. You just need its pubkey, which can live in your password manager or wherever.

And yet, if your house burns down, you can go get that smart-card, and use it to get back into all your services.

And yet also, unlike a backup of another of your keys, if you find out that someone broke into your house and stole your safe, or robbed your bank, etc, then you can separately revoke the access of the pubkey associated with the smart-card, without affecting / requiring the rolling of the keys associated with your other devices. (And the ideal additional layer of passphrase protection for the card, gives you a time window to realize your card has been taken, and perform this revocation step, before the card can be cracked and used.)

Indeed, as the sibling comment mentions, this is vaguely similar to a (symmetrically passphrase-encrypted) backup of a unique extra KPI keypair onto a USB stick or somesuch.

The major difference, though, is that because a backup of a key is truly "just data", an attacker can copy off the encrypted file (or image the raw bytes of the encrypted USB disk), and then spawn 10000 compute instances to attempt to crack that encrypted file / disk image.

Whereas, even when in possession of the smart-card, the attacker can't make 10000 copies of the data held in the smart-card. All they can do is attack the single smart-card they have — where doing so may in turn cause the smart-card to delete said data, or to apply exponential-backoff to failed attempts to activate/use the key material. The workflow becomes less like traditional password cracking, and more like interrogating a human (who has been explicitly trained in Resistance-to-Interrogation techniques.)