HN user

christoff12

137 karma

Currently working on Pageplane.app

chris@bootstrapital.com

Posts2
Comments94
View on HN

I have no affiliations with the team or product, but Superconductor reminded me of Jules when I tried it a couple of months ago.

It might be overkill features-wise, but there's a free tier and it likely won't be left for dead anytime soon.

Re: difference -- Ok, I think I understand. Ultimately, we need a "permissions" layer and you've built a solve for that.

Re: README -- I can't recall a specific repo with one off the top of my head so took a stab at editing yours[1] instead of hunting around. It's not perfect -- I'd want to trim the bullet lists further, for example -- but is much more scannable in my opinion.

---

[1] https://gist.github.com/thedatadavis/fbbe556348eb43731659456...

The runtime holds the credential and only lets it through the skillscript I approved.

What about skillscript is unique that couldn't be done with bash or python as a permissioned tool? (Trying to understand where you see the difference.)

---

My original impression from the repo was that the language/toolkit is overengineered, but then I saw on the website that the intention is for the agents to write their own tools. That helps explain some of the complexity.

I think the rest of the perceived complexity is the over-explaining in the README.

I don't think anyone's going to really engage with all of that so you might have better luck chopping it down 80% to only highlight the stuff that matters.

Due to the way Bibtex works, you may need to compile at least three times to see correct reference numbers in the PDF.

I'm not sure I understand why the second or third compile would work, but not the first.

I hear you -- you and other teams are capable of building internal versions that just work.

I'm equally excited -- I've spent much of my career building janky internal versions of popular SaaS out of necessity since we didn't have the budget to buy. To be able to do a better job with less effort is enticing.

But this is: a) a step-change that hasn't had a full year to bake; we should all anticipate the pain associated in the medium term after a few iterations, inevitable feature add-ons, etc. b) beside the point.

Yes, many teams can also build internally, but it doesn't change the fact that others find value in outsourcing. Just because it's much easier, or rather __because__ it's easier to stand stuff up, it's imperative we prioritize what gets built.

If [Anthropic](https://fin.ai/customers/anthropic) themselves are willing to vouch for the value-add, I think it's silly to suggest that teams with budget and higher priorities should trade the time and focus to roll their own.

Many, many people do not have the capacity to build and maintain custom solutions (whether in-house skills, or simply bandwidth) and therefore outsource to vendors.

It's an incredibly common aspect of business. Enterprise level contracts often include the sort of white glove service to help fill in these sort of gaps. On simpler plans, having the tooling provided frees up just enough capacity to handle the exceptions to keep the process running smoothly (since one doesn't have to build and run simultaneously).

Sometimes people want to minimize the hassle with stuff. It's why car washes and oil change places and coffee shops exist.

Belated follow up: I was able to install the agy cli directly without the IDE (perhaps this was a change made in the interim).

I ran it last night and it was just fine as a drop-in replacement for my usage. Disappointment averted with minimal effort on my part (it helps that my typical workflow is pretty mundane/close to the defaults).