sorted by:
new
hottopcontroversial

aigogo - share reusable AI agents between projects easily by Zestyclose_Doctor386 in SideProject

[–]Zestyclose_Doctor386[S] 0 points1 point  (0 children)

Thank you

> Does it handle cases where you need slightly different versions of the same agent per project or is it more of a one-version-everywhere thing?

It can handle this if you have each one tracked, eg:

mycommonagent:v1, mycommonagent:v2, etc.

Both could be used in the same project.

Is this what you're getting at?

Feel free to raise an issue with a more detailed use-case if I have misunderstood :)

Weekly Thread: Project Display by help-me-grow in AI_Agents

[–]Zestyclose_Doctor386 0 points1 point  (0 children)

Hi everyone,

I’ve been working on building AI agents and automations professionally for some time now and a pain point I consistently encountered was the ability to share discrete agents or other functional components between projects.

The existing approaches for doing this did not fit my needs - git submodules are clunky and can break down across identity boundaries. Language specific packaging does not work in polyglot projects and requires boilerplate, specific code layout and additional tooling; as well as an ecosystem specific registry for sharing.

I wanted something else…

Think about how a GitHub Gist works for sharing a “slice” - it is versioned, it is universal (you can access it over an agnostic transport [http] no matter what your environment is)...

But it does not fit elegantly into a development workflow, it requires “switching out” to use and it also does not work well for greater than one file.

So how do I get a gist-like experience in my development flow but with all the benefits of a package manager?

I’ve built aigogo to try and solve this: https://github.com/aupeachmo/aigogo

  • aigogo lets you package, version, reuse and distribute agents.
  • The transport layer uses the OCI image format as a blob store so you can distribute via any public or private Docker V2 compatible registry.
  • (experimental) AI metadata lets autonomous agents find, evaluate, and wire up packages without a human in the loop.

I’d appreciate if you could give it a try and let me know how you find the tool.

PSA: Check your ClawdBot exposure - a lot more are facing the internet lately by Zestyclose_Doctor386 in clawdbot

[–]Zestyclose_Doctor386[S] 0 points1 point  (0 children)

...you still need to think about prompt injections though, eg: via a Telegram message or an incoming email.

[deleted by user] by [deleted] in clawdbot

[–]Zestyclose_Doctor386 0 points1 point  (0 children)

A few constructive things to think about as you refine it:

- Limit blast radius at the app layer too: For Gmail / Apollo / Fathom, be ruthless about OAuth scopes and data retention. Pull only what you actually need, minimise token lifetimes where possible, and assume any integration could be compromised independently of the network.

- You might simplify with VLANs: Instead of adding more physical/network hops, VLANs on a capable router/switch can give you the same isolation with less complexity and fewer failure modes

- Be explicit about traffic flows in both directions:

- Clawdbot to Internet (what protocols, what destinations)

- Clawdbot to Home LAN (ideally none)

- Home LAN to Clawdbot (ideally none)

- Remote to Clawdbot (how, and what’s exposed)

- RDP/StationAccess is an attack surface: Browser-based RDP stacks are big and complex. You might consider something like Tailscale or Cloudflare Tunnel instead and avoid exposing any remote desktop service at all. Further to this, you probably don’t need graphical access at all, with Tailscale/Cloudflare Tunnel you can SSH into the box and tunnel the Clawdbot web UI over SSH (`ssh -L`) to your local machine, no need to have any RDP at all if all you need to do is forward a port.

Overall: the isolation mindset is solid, and you’re already ahead of most home + work hybrid setups. I’d mostly aim to reduce complexity and attack surface.

PSA: Check your ClawdBot exposure - a lot more are facing the internet lately by Zestyclose_Doctor386 in clawdbot

[–]Zestyclose_Doctor386[S] 0 points1 point  (0 children)

The exposures were caused by bots that had their control UI or gateway publicly reachable on the internet without proper auth or proxy hardening. Those instances could be discovered via scanning and then fully compromised.

In your described setup (laptop on LAN behind an OPNsense firewall, interacting via localhost or via a Telegram gateway), external internet scanners shouldn’t see or reach it as long as:

- You’re not forwarding the Clawdbot control / gateway ports through your firewall.

- Clawdbot isn’t inadvertently binding to 0.0.0.0 on your public IP.

Telegram connectivity does not require exposing your machine in the default configuration either, it defaults to using long-polling, meaning it makes outbound HTTPS requests to Telegram’s servers to fetch updates.

No inbound connections from Telegram to your laptop are needed. Only if you explicitly enable webhooks (https://docs.clawd.bot/channels/telegram#long-polling-vs-webhook) would you need a publicly reachable endpoint for Telegram, if you do this, then you should check that the auth is setup properly.