Allowing dynamic config of apps through our APIs

[ObnoxiousProxy]

@kanlanc kicked off an interesting discussion today on LinkedIn. Reproducing the thread here.

@kanlanc : Yo @ObnoxiousProxy , is there a reason why dynamic apps or agents config has not been setup on ACI?
Like yes I can manually configure agents and apps, but dynamic config was something I was looking for and am curious on that

@ObnoxiousProxy : good call out, we're looking to implement this but still debating the best way to do it. At some point when A2A first came out we were considering creating an A2A server out of our entire platform for agents to configure the tools they need automatically. Would be keen to ping you and figure out the best DX for this at some point!

@kanlanc : Thats a cool idea, why not go for the existing route, when asked for a new integration, default to oauth 2 and send a oauth link back to add that integration?

@ObnoxiousProxy : This is already supported when an app is configured. When an app is configured you can return an OAuth2 URL to the user to authenticate, but setting up the app configuration itself right now is not dynamic, though we are looking to support that too.

@kanlanc : That is super interesting, I would imagine that is only a couple of lines of code or depends on how services are architecture maybe proxying around to an end.
Since it's OS, I can look into it on my time but curious to know what's blocking this rn? Is it just priority?

@ObnoxiousProxy : It's not hard to ship but there's a lot of branching and nested design decisions for this and it just hasn't been prioritized. Some examples:

• If we dynamically configure an app we may also have to decide whether to allow the developer to dynamically provide their custom OAuth2 client during this process or only default to what we provide
• Whether to only support dynamically configuring apps that support OAuth2 or other authentication methods
• If we allow dynamic configuration, why not simply configure all apps that are available on the platform by default
• Currently app configuration is tied to an overall project which can contain multiple API keys, but access to configured apps is based on individual API keys (which can but not necessarily need to represent individual agents) -- if we allow dynamic configuration do we allow privilege escalation from the individual API key for that? What would be the security implications? Alternatively we can support only allowing dynamically configuring apps when using some project ID

Overall it's a series of design decisions that we haven't had reason to prioritize yet, but would be keen to hear if you have a specific use case where this is essential.

@kanlanc : First, thank you for the design decision tree, I see where your coming from.

Thinking from ACI perspective as a company, to my head it would make sense, if you offered ACI default OAuth especially if the dev is using the platform. This would increase both speed of setting up ACI but also retention, purely thinking from ACI perspective.

Whether to only support dynamically configuring apps that support OAuth2 or other authentication methods --> Beyond OAuth and token, what other methods have you come across?

If we allow dynamic configuration, why not simply configure all apps that are available on the platform by default --> That literally made sense to me lol especially if your offering the platform as a service

Currently app configuration is tied to an overall project which can contain multiple API keys, but access to configured apps is based on individual API keys (which can but not necessarily need to represent individual agents) -- if we allow dynamic configuration do we allow privilege escalation from the individual API key for that? What would be the security implications? Alternatively we can support only allowing dynamically configuring apps when using some project ID --> Yup, I was thinking the last part

You mentioned this

---

At some point when A2A first came out we were considering creating an A2A server out of our entire platform for agents to configure the tools they need automatically

---

How is this different from dynamic config? The only diff to me is if the agent is doing it or me as the dev

Lol, best part of being OS is that, we can have this as part of the discussions in the github repo than on Linkedin, the whole community would be able to contribute with more context

@ObnoxiousProxy : Haha good shout about having this as a discussion on GitHub, will move it there after this response. Your comments to all the points all make sense and some are answers we arrived at at some point, but we decided not to implement them yet because these decisions are ultimately just one possible opinion from developers. We are of the mind that we shouldn't do extra engineering when there's no clear advantage of one opinion over another when there are more important priorities with clear use cases that the community is asking for.

If we had implemented A2A then we would definitely decide on each of the items we discussed, and we ultimately didn't ship the A2A server yet because we weren't convinced there's a strong utility for it at the moment.

---

Keen to get commuinity feedback on this if anyone has wondered something similar or has a strong opinion on this!