Really cool direction. For folks thinking about the “agent safety” stack more broadly, this feels complementary to things like Kontext’s kontext-cli (github.com/kontext-dev/kontext-cli) and OneCLI (github.com/onecli/onecli)
A lot of current tooling is layered mostly at the workflow level. Auth for the agent, or memory management for the agent (like some smart skills stuff), but Forge sits below that.
In most cases I've looked at, it could be slotted in with other work without much disruption. Forge just increases mechanical reliability of tool-calling, it shouldn't disrupt your workflow-level layers much.
I have indexed skills from trusted repos and github. And giving semantic search for the agent, along with ranking based on stars, forks, installs etc.
Trying to create a flywheel loop as well, where agents can rate skills and that gets incorporated in the ranking.
hm i see so a bit like pagerank for md files - would be curious about the equivalent to backlinks, what do you think that is for skills? Skills that embed other skills?
That is like a dependency thingy. Like browser harness by browser use is a skill. Using linkedin is a skill on top of that. Doing cold outreach on linkedin is probably a skill on top of that, and you can keep going.
I think if I install the cold outreach skill, I'll also have the browser harness skill as well, so the ranking algo will already rank it higher.
Nice, I think that's pretty neat. Do you have an idea where to take this further? I.e. for the filesystem it's great but what if you need to touch external systems that keep their own state?
In a perfect world, every system and external API would expose a standardized interface for versioning its own immutable state, so you'd be able to rollback and time travel across multiple such systems.
Not sure what else we can do in this world other than tightly control outbound requests and provide enough visibility into those requests for a human|agent to try and undo changes.
Happy to hear your thoughts - what would you like to see us take this?
Yeah tbh I think this might be close to impossible to do as it probably 1) requires alignment that every stateful system needs a rollback capablity 2) it needs to be standardized which will probably take a minimum of 2 years after consensus (and that's probably conservative).
I'd love to learn more on how egress can be handled securely in sandboxes, and in general also ingress as this has some security impact - as soon as you allow reading from an external system you open up a new threat vector. Curious to understand whether you have any strategy for network access?
That’s the current RBAC implementation: agents by default can make no API calls. the only way for them to contact the outside world is through a forward proxy configured in the sandbox. that proxy only allows making requests to destinations explicitly allowed (host, path, method)
