I encountered this with trying to have LLMs populate facts about electoral campaigns. Like when a candidate drops out, when endorsements happen, but also if a candidate is un-endorsed or drops and rejoins. It also needed to handle if any of these facts were incorrect.
I settled on a knowledge graph in Postgres and downloading/storing the source documents so it could iterate on past results without more scraping or network calls.
This blog post helped me understand security analysis in this context! A lot of the important systems around malware analysis or large scale system security (the parts people really care about) clicked for me. So thanks for writing it.
Anyways I hope we can find some pattern to converge on with this wrt "facts management" since I feel this is currently something a lot of people and LLMs are struggling with. In practice current LLMs working with episodic memory feels similar to a grandparent with dementia scrawling things down in notebooks, crossing things out, and getting very confused.
I had similar problems to solve for trading advice, complex project reasoning etc.
I settled on simplicity, extended it to serve clear, useful purpose.
Started with markdown database, single fact per line, structured/parseable (subject VERB object). This can be easily diffed/reviewed etc in git. Then added optional metadata (confidence, tags, persisted comments for natural language, uncertainty for numeric values, context, timestamps/spans), querying, alternative sqlite3 backend, self describing VERBS, z3 solver etc.
Those kind of graph information systems are great to quickly structure knowledge in a way that LLMs and humans can use/act on/loop on. Creating ontology, linking, some rules and actions and kicking it so it all munches and spits out results that feed back in so it self evolves. It's very natural for llms to query/update/restructure those graphs (also good for humans because it's very terse, essential information only).
There is no need to create k8s style complexity/services/what-not, it all works well from single sqlite db file or bunch of markdown (.cave in my case) files.
It's also interesting to see how well local open weight models are dealing with information arranged this way.
I disagree, the approach works well in a legacy project, since there are structures and standards that already exist, which them model can draw from (if you aren't more explicit about it in AGENTS.md)
I spun up an Debian stable ec2 vm (using an agent + aws cli + aws-vault of course) to host openclaw, giving it full root access, and I talk to it on discord.
It's a little slow sometimes, but it's the first time I've felt like I have an independent agent that can handle things kind of.
The only two things I did were 1. Ask it to create a Monero address so I could send it money, and have it notify me whenever money is sent to that address. It spun up its own monerod daemon which was really heavy and it ran out of space. So I had to get it to use the Monero wallet instead, but had to manually intervene to shut down the monerod daemon and kill the process and restart openclaw. In the end it worked and still works.
2. I simply asked it "@ me the the silver price every day around 8am ET" and it just figured out how to do it and schedule it. To my understanding it has its own cron functionality using a json file.
3. Write and host some python scripts I can ping externally to send me a notification
I've had it done other misc stuff, but ChatGPT is almost always better for queries, and coding agents + Zed is much better for coding. But with a cheap enough vm and using openrouter plus glm 4.7 or flash, it can do some quirky fun stuff. I see the advantage as mainly having control of a system where it can have long term state (like files, processes, etc) and manage context itself. It is more like glue and it's full mastery and control of a Linux system gives it a lot of flexibility.
Think of it more as agent+os which you aren't getting with raw Claude or ChatGPT.
I've done nothing that interesting with it, it's absolutely a security nightmare, but it's really fun!
Hate to be the guy in the comments complaining about the css, but the sides of the text of this article are cut off. It looks like I'm zoomed in, and there's no way I can see the first few columns of the text without going to Reader view. I'm on a modern iPhone using safari, accessibility settings font larger than usual.
> Autoscaling is configured via CloudWatch alarms on CPU usage:
> Scale-out policy adds workers when CPU > 30%.
> Scale-in policy removes idle workers when CPU < 20%.
Does this handle the case where there are longer-running activities that have low CPU usage? Couldn't these be canceled during scalein?
Temporal would retry them, but it would make some workflow runs take longer, which could be annoying for some user-interactive workflows.
Otherwise I've seen needing to hit the metrics endpoint to query things like `worker_task_slots_available` to scale up, or query pending activities, pending workflows, etc to scale down per worker.
They can be cancelled if CPU drops below the scale-in threshold.
In my case the activities were CPU-heavy, batch-style, and not client-facing — so preferred occasional retries and slightly longer runtimes over blowing up the AWS bill. For that workload, CPU-based autoscaling was perfectly fine.
I originally ran this setup on Temporal Cloud, and pulling detailed worker/queue metrics directly from Cloud can be tricky... you need to expose custom worker metrics yourself, then pipe them into CloudWatch. If you host Temporal yourself, it is easier:)
reply