An0n_Jon

Yeah, this is the reasons why Orloj has built in policies which are applied to your resources and managed at the runtime level. This way you can allow only certain tool usage per agent for a more fine grained setup.

Yeah the governance is also built into Orloj as well as applied policies. More so acting as guardrails at the runtime level. Ill take a look at agentveil and would love to know your thoughts on Orloj as well.

Yeah, agreed it feels like overkill keeping the resource running if nothing is calling it. Even with read only you still have the issue with wasted resources but I get what you mean.

Orloj is a runtime with policies you apply as guardrails to keep agents in check for tools and other limits which all happen at the runtime level. And building out the tooling it just made sense to containerize tools so they can be spun up on demand and stay alive when needed and spin down after.

Yep, totally agree. And Orloj has this built in. Tracks the entire lifecycle of your tasks through traces in real time so you can audit why everything happened good/bad. During your task you can see how many tokens each call used (input/output), and latency for each model/tool call.

Definitely understand the perspective. I think with all software in general there will be a time where you need to adapt to changing technologies/architectures which is why we open sourced the core so we can have contributors build off it. And k8s is loved/hated but it does solve a lot of problems depending on the circumstance.

Didn't realize the Czechs had so many...The story about the clockmaker on the Prague one was interesting. The king trying to blind him so he could never make another for anyone else...

This is where the governance layer of Orloj fits in. You create policies and attach them to agents/tools which are all governed at runtime. These policies could be token guardrails, tool authority, etc. You can then check all of the traces of a task to have an audit trail for debugging (cli or UI). There are also human in the loop approval features that can be applied to make sure things are working correctly before proceeding on tasks.

It depends on what you're trying to build to be honest. For simple tasks Orloj can be a little overkill but it really starts shining when you are trying to setup large task flows that need many agents/tools/policies. Working with Terraform/Kubernettes for years gave a lot of the inspiration for the gitops side of things which we think fits naturally with how agent systems work.

Yes! We visited The Prague Orloj 2 years ago and it's amazing engineering. That's why we named it after it, for how it's coordinating and orchestrating so many complex mechanisms. (for anyone wondering it's pronounced Or-Loy)

This is interesting. It says agents self register...How do agents find this? And why would they decide to create a profile? Wouldn't they be costing their owner tokens to do this?

Hi HN — I built kroot to help debug Kubernetes failures by tracing dependencies between resources.

Instead of only showing symptoms (CrashLoopBackOff, etc), it builds a dependency graph of cluster resources and tries to answer:

"Why did this actually break?"

Example failure chain it can detect:

Secret/prod/db-password missing ↓ Pod/prod/payments-api CrashLoopBackOff ↓ Service/prod/payments has no endpoints ↓ Ingress returning 503

Would love feedback from people running Kubernetes in production.