andreisavu

Hi HN — I’d love feedback on a starter repo for building unattended/background agents in Python:

https://github.com/weakincentives/starter

It’s built on top of WINK (Weak Incentives). The goal is to make the “agent definition” a first-class artifact: prompt structure + tools + policies + feedback/evals, separated from whatever runtime/harness drives the loop.

The demo is a toy “secret trivia” agent, but it showcases: prompt sections that bundle instructions + tools, progressive disclosure, tool policies (ordering constraints), feedback providers, and evaluators.

Questions: - How are you approaching building agents that run unattended? - Are these abstractions useful, or would you do this differently? - What works? What doesn't? What feels weird?

Thanks for any critique.

If you try it, I’m most interested in where the abstractions are too thin or too heavy or lacking.

Install: uv add weakincentives (extras as needed)

Start with the code‑review example; it ties together prompt construction, overrides, telemetry and using the adapters.

Status: Alpha; APIs may change

Roadmap: parallel sub-agents, built-in GEPA prompt optimizer that uses the overrides store

Most System Dynamics (SD) software still treats a model like a slide deck. I wrote a short piece arguing that models should live as code—versioned, tested, observable, and fed by real‑time data—just like any service. It sketches the platform building blocks (registries, query engines, runtimes) rather than pitching a monolith.

I’m interested in counter‑arguments: where does the diagram‑first approach still win?

Did you also consider Java or any JVM-based language?

Modern Java is a lot less verbose than it used to be and it knows a lot of tricks (e.g. akka, play framework, dropwizard, Rx, dependency management, good IDEs, advanced profiling and instrumentation etc.)

Netflix is an excellent example of how you can leverage the JVM to build one of the most advanced system architectures hosted on AWS.

we are planning to add some features that depend on that email address (some sort of advanced client profile)

required but not unique. just generate a dummy one based on the user id.

Sunnytrail does not enforce an unique email address or an unique username. We are tracking users based on the supplied internal user ID (or an email address hash if an internal user ID is not provided).

Hi Brad! I'm glad you like Sunnytrail. Your problem can be easily solved. I suppose that you are generating for each users some sort of unique ID. My advice is to use that to generate an username (if not already available) and a dummy email address. You should be able to update those later when that customer upgrades to a paid plan. TweetSaver looks great! Get back to us on email if you've got more questions.

that was quick! thanks Richard!

We are working mainly on this. We don't have a regular job.

Honest answer: I also care. It's not like we are trying to hide something. Most of the time Octav it's available on the Live Chat and we write individual emails to all the users that signup for the service. As side note security is really important for us and we are taking all the measures needed to ensure data privacy.

We are two founders: Octav Druta http://www.octavdruta.com/ and Andrei Savu http://andreisavu.ro/ working from Bucharest, Romania. We've got no investment so far.

Exactly and that's just the beginning. We are working on adding more metrics and better visualizations.

I believe you can write a wrapper in node.js in minutes. Check the raw API docs at https://www.thesunnytrail.com/developers I would do it myself but I'm not familiar with node.js. Let's get in touch. You can find me at [email protected]

Thanks for feedback. You are unable to click on Stream, Overview or Plans because you haven't sent any data. I agree this behavior can be improved. :)