Comments URL: https://news.ycombinator.com/item?id=48513536

Points: 487

# Comments: 477

Comments URL: https://news.ycombinator.com/item?id=48503839

Points: 2

# Comments: 0

(great article!)

Comments URL: https://news.ycombinator.com/item?id=48426730

Points: 4

# Comments: 1

One issue that a lot of teams run into is that they want to switch their configs between different agents e.g. Claude Code --> Codex or they want to switch out different configs for the same agent e.g. using a different set of skills and CLAUDE.md for debugging vs feature engineering.

We've been working on an open source AI configuration manager. You can use it to manage / maintain your agent configs entirely locally, or share them with the public / your team.

For example, say I have a few different configs that I want to switch between:

- a production-debugging config that I use to get Claude to ssh into a remote machine and look at logs. This has strong guardrails around not changing anything and provides a step by step guide on where logs exist

- a high-autonomy config that I use for feature work

- an admin config that I use for things like making slide decks or recording voice notes

I can switch between these with a single command, for e.g. ``` sks switch administrator ``` and the configs will swap themselves out.

You can specify which agents you want to use by running `sks config`, and you can set which directory to run in so that these configs are isolated by default.

This has been really useful for me because I spend a fair bit of time crafting specific skills for specific uses and often want to switch between claude 'personalities'. And more recently, I switched to codex, and it was nice to be able to seamlessly port all of my configs without having to figure out what to do with each one.

Cheers!

Comments URL: https://news.ycombinator.com/item?id=48398177

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48397769

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48247681

Points: 2

# Comments: 0

keys are tricky. We don't have a great answer. I mean the proxy inject works well enough for mcp, but there is just such a long tail of tools that do something like 'read a key from disk and encrypt it before sending it out' which makes proxy management just a pain

A few questions

- you mention proxying keys. One issue that we run into is that there are a bunch of tools that are really useful but require keys to be on disk (e.g. aws cli -- yes yes you can do IAM permissions but still). How do you guys think about those? (Especially since your setup onboarding is 'just install from npm or mise')

- poking around on the github, saw that you guys were at one point on fly.io. Did you guys end up switching off them? What motivated that if so?

- the CLI integration is cool! Is that actually teleporting remote sessions down to a local machine? Or is it more a window into the remote sandboxes?

would love to share notes! If you want to get in touch separately feel free at amol at noriagentic dot com.

Comments URL: https://news.ycombinator.com/item?id=48183062

Points: 5

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48148482

Points: 2

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=48137625

Points: 5

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48136098

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48100923

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48008689

Points: 4

# Comments: 0

My team and I have been building a background agents as a service product. One of the things we needed pretty early on was for some way for the agents to be able to drive slack.

Right now, I don't think there are many good agent-first ways of doing this. I don't love MCP -- it's just too many tokens in the context window, and agents seem to do better with CLIs because they can embed them in code and so on. But other CLIs that exist are either a) subsets of the web api that only focus on human needs and b) have polished terminal UIs with spinners and colors and interactive things that make it hard for LLMs to actually use them.

nori-slack-cli is a very thin dynamic wrapper over @slack/web-api (i.e. bolt). Whatever the SDK can call, the CLI can call. When slack adds a new method it should just work without a new release on our end. (Inspired by the GWS cli: https://github.com/googleworkspace/cli).

So you(r agent) can do things like:

`nori-slack chat.postMessage --channel C123 --text "hi"`

`nori-slack admin.users.list`

`nori-slack bookmarks.add`

etc.

It's pretty easy to build a cli these days, so what makes this special? We spent a bunch of time thinking about what is necessary to make something 'agent first', which is I think the real value of this CLI: the design stuff.

- Every response is a one line JSON on stdout, no colors or interactivity.

- Every error includes a source field with the on-disk path to the CLI. When the agent is confused it can just go read the source (also useful for asking the agent to go add a feature on the fly)

  - (Re the above, we generally recommend downloading and running the cli from source on your machine!)

- there's a list-methods function for discovery

- the 'paginate' flag auto-cursors and merges pages into a single response

- and my personal favorite: any unknown method will try and Levenshtein fuzzy match to surface other methods the agent may have meant

We purposely wanted the CLI to match the bolt API 1:1 because we felt it critical that the agent had the capability of doing anything it needed. Scopes are managed via the tokens the cli has access to.

Repo: https://github.com/tilework-tech/nori-slack-cli

Would love to hear feedback about what works for other people when designing cli products for agents

Comments URL: https://news.ycombinator.com/item?id=47978764

Points: 1

# Comments: 0