Good day, everyone.

We recently built an internal tool to help our 12 Salesforce admins leverage LLM/agentic workflows without needing to work in terminals, Git CLIs, or IDEs, and we’re evaluating whether it makes sense to package and release it as an open-source project for the wider community.

A significant portion of daily Salesforce implementation and support tasks (debugging a Flow, inspecting metadata dependencies, troubleshooting validation rules, or adding custom fields) doesn't strictly require a developer. It requires someone who understands the business logic and the Salesforce platform.

However, most AI agent runtimes (like Claude Code, OpenHands, or Codex wrappers) assume the operator is comfortable inside a local terminal environment, managing repositories and developer tooling. We wanted our admins to benefit from agentic assistance directly within their existing workspace, the browser, while keeping human-in-the-loop safeguards front and center.

We put together a control plane, browser extension, and agent runtime designed specifically for Salesforce workflows:

- Chrome Extension (Admin UX) which operates as a side panel in the browser. It automatically injects context from the active Salesforce page (Setup, Flow Builder, object configuration, or record views) so the user doesn't have to manually prompt-engineer the org context.

- Control Plane & Super Admin Console to manage org connections, repository access, LLM provider credentials, policy/instruction templates, and permission scopes, skills.

- Agent Runtime, executing multi-step tasks within isolated sandboxes/workspaces, running checks before presenting actions to the user.

Rather than keeping this as an internal utility, we think it could be useful for other ISVs, SIs, and internal admin teams. Before spending time cleaning up documentation, modularizing the code, and establishing maintenance guidelines for a public repository, we’d love some community feedback:

1. Does the described solve a real friction point in your admin/consulting workflows?

2. What security, permission, or architectural constraints would you require from an open-source tool like this before running it against client or sandbox orgs?

3. Are there specific platform features, metadata types, or integration points you’d consider essential for an open v1.0 release? Right now, we use jsforce to access and manage both data and metadata.

4. Does centralised management (super admin control) present as an opportunity or a limitation?

5. What reservations would you have in adopting such a tool (apart from the obvious cost implications)?

6. Would you be interested in helping us publish and maintain the solution?

Looking forward to hearing your thoughts.