An AI agent finds a likely cause. Another agent knows how to fix it. Why should an engineer have to manually carry the answer from one tool to the next?
For years, incident response has been organized around human handoffs: an alert arrives, someone investigates, another person prepares the fix, and someone else approves or executes it. AI can shorten the investigation, but if every result still ends in a manual handoff, the operating model has barely changed.
Agent-to-agent collaboration opens up a different possibility: AI systems investigate, exchange evidence, and carry out permitted actions while engineers supervise the whole process.
That is the shift from human-in-the-loop to human-on-the-loop. And it depends on something more fundamental than the agents themselves: knowing the infrastructure they are operating on.
In the loop: humans move the workflow forward
In a human-in-the-loop workflow, a person is a required decision point. The AI can suggest a root cause or prepare a change, but a human must approve the relevant step before work proceeds.
This is appropriate when the consequences are high, the evidence is uncertain, or policy requires explicit authorization. It also means the workflow can spend time waiting for someone to review work that may be routine.
Human approval is a control mechanism. It is not, by itself, a complete operating model for autonomous incident response.
On the loop: humans supervise a moving system
In a human-on-the-loop model, people establish the boundaries, monitor the system, and retain the ability to intervene. Within those boundaries, agents can continue without requesting permission at every handoff.
An investigation agent may identify a likely cause. An execution agent may assess whether a predefined remediation is allowed. A verification step may confirm recovery or escalate when the result is unexpected.
The person responsible is not absent. Their role changes from manually advancing each step to governing and supervising the workflow.
That requires explicit permissions, action limits, audit trails, reliable stop mechanisms, and escalation paths. High-risk production changes can still require approval. On-the-loop is not a synonym for unrestricted production access.
Agent-to-agent changes what happens after the diagnosis
A faster root cause assessment is useful. But the bigger opportunity appears when that assessment can become structured input for another trusted agent.
Consider a hypothetical checkout incident:
Investigate. An infrastructure-aware agent connects alerts with available service dependencies and recent changes. It identifies a possible database connection-pool issue and the services that may be affected.
Share the evidence. The findings, uncertainty, and suggested next actions are made available to the team's engineering agents or automation workflow.
Evaluate the action. An execution agent checks the proposed remediation against access policies, change rules, and the available runbook. A pre-authorized, reversible action may proceed. A higher-risk change is escalated for approval.
Verify the outcome. Health signals are rechecked. Unexpected results trigger an alert, rollback process, or human intervention according to policy.
This is an illustrative future-state workflow, not a claim that every step is already available in Parny today.
The important shift is that investigation and execution no longer have to be isolated tasks connected by manual copying and pasting. Agents can collaborate while each retains a defined role and permission boundary.
The autonomy problem nobody solves with another approval button
An agent may be capable of issuing a rollback or restarting a service. That does not mean it understands everything the action will affect.
Which applications depend on the affected database? Is the failing service the root cause or merely a symptom? Could the proposed fix degrade a separate workload? Is the service map current, and which relationships are still unknown?
Those questions are not solved by giving an agent more tools. They require infrastructure context: discovered assets, service dependencies, operational signals, and evidence that connects a proposed action to its likely impact.
A service map is not an infallible picture of production. It is a model that must be checked against current telemetry and recent changes. But it gives investigation and execution agents a shared starting point, rather than forcing each agent to reason from a different fragment of the environment.
Agent-to-agent collaboration moves the work. Infrastructure understanding helps determine whether that work makes sense.
Where Parny is going
Parny's foundation is the operational understanding it builds from its own agents and integrations with existing tools. Service Map and Infrastructure Visibility help connect hosts, services, and dependencies. Parny AI uses the available context to produce root cause assessments, impact analysis, affected services, and prioritized next actions.
The direction from here is agentic: making that infrastructure intelligence available through developer and SRE workflows, and enabling closer collaboration with the agents customers already use.
Through MCP, infrastructure context can become accessible to the AI tools engineers already use. Through agent-to-agent collaboration, that understanding can move beyond investigation into coordinated action. Parny's direction is to connect these two worlds: the system that understands the infrastructure and the agents that can work on it.
The goal is not simply an AI that explains an incident. It is an infrastructure-aware system that can support a coordinated response across agents, with humans supervising decisions, permissions, and outcomes.
This is the human-on-the-loop future Parny is building toward, not a statement that fully autonomous remediation is already shipping.
The next operating model
Human-in-the-loop remains essential where risk, uncertainty, or policy requires explicit approval. But it shouldn't be the default for every step.
The next generation of incident response is moving toward agents that investigate, collaborate, and act within defined boundaries, while engineers supervise the system.
And autonomy raises a critical question:
Does your AI understand your infrastructure well enough to know what its actions might affect?
That's the future we're building toward at Parny.
Agents move the work forward. Humans stay in control.
