A delivery platform built around screens and mouse clicks assumes a person is doing the work. That becomes a constraint when developers delegate tasks to coding agents from inside their development environments. Exposing the same capabilities through APIs, command-line tools and agent interfaces changes how work reaches the platform, but it does not remove the need to test changes, enforce security checks or decide which actions still require a human.

Federico Larsen, co-founder and CTO of Copado, joins Alan Shimel to explain that shift through the lens of Salesforce development. Larsen describes three access layers: APIs, CLI commands and packaged agent skills or MCP servers. Developers using tools such as Cursor and Claude Code can delegate work without having to move every step back into a graphical interface. The design accommodates autonomous execution as well as workflows that keep people involved in decisions.

Giving an agent more access also expands what teams must validate. Larsen points to connected applications, IP ranges and agent behavior as areas that need security scrutiny, alongside quality gates earlier in the delivery process. Testing an agent adds another complication: its responses are not necessarily identical from one run to the next. Teams need to assess whether it stays on task and follows corporate language requirements, rather than relying only on a fixed expected answer. He also describes generating regression tests from user-story acceptance criteria.

The distinction between making a platform accessible and making it safe to automate runs through Larsen’s examples. An API can expose an operation, but the surrounding workflow still needs checks on the changes an agent produces. His account connects headless access with testing and compliance, not simply the removal of a user interface. As agents take on more delivery tasks, those controls need to remain part of the path from a developer’s request to an accepted change.