The Software Ops Agent Framework is Keepstone's operating model for custom software. It applies eight standard layers to each system, gives bounded work to agents, and keeps business-critical judgment with named operators. The application stays in the client's accounts and on its existing stack; the framework standardizes how it is observed, changed, secured, documented, and recovered.
This is not a claim that an agent can run a business system without oversight. It is a division of responsibility: software handles repeatable operating volume, while people remain accountable for scope, architecture, and risk.
What the Software Ops Agent Framework is
The framework combines four elements at every layer:
| Element | What it provides | What should be inspectable |
|---|---|---|
| Tools | Access to the application, infrastructure, telemetry, and delivery systems | Connected services, permissions, and audit logs |
| Agents | Scoped workers for detection, diagnosis, documentation, and low-risk changes | Instructions, allowed actions, and execution history |
| Standards | A consistent operating baseline across different technology stacks | Repositories, runbooks, checks, and configuration |
| Operators | Named people who own fit, exceptions, and consequential decisions | Escalation paths, approvals, and decision records |
A framework-compatible system is not one rewritten onto a Keepstone stack. It is a system whose operating seams are explicit enough that a qualified operator can understand its health, make a reviewable change, recover it, and hand it over without relying on one person's memory. The framework page shows the same model as a layer-by-layer operating diagram.
The eight operating layers
1. Engineering workflow
This layer controls how changes are proposed, tested, reviewed, and reversed. Source control, branch rules, automated checks, change descriptions, and rollback paths make agent-authored and human-authored work inspectable before it reaches production.
The control is simple: no change should depend on trust in the author. The repository and delivery process should show what changed, why it changed, what checked it, and how to reverse it.
2. Infrastructure and DevOps
This layer covers the production environment and the route from a reviewed change to a release. It includes environment separation, secrets handling, version-controlled configuration, deployment checks, and rollback procedures.
The agent's scope is bounded by those controls. A deploy agent can execute a known release procedure. It should not make an unreviewed architecture decision because a release failed.
3. Observability
Observability makes the system's behavior visible. Uptime checks, synthetic transactions, structured logs, error tracking, latency, queue depth, and cost signals turn “the app feels wrong” into evidence an operator can inspect.
Detection is useful only when it leads to a decision. The operating record should connect a signal to a diagnosis, an action, an escalation, or a documented reason to do nothing.
4. Triage and support
This layer turns reports and alerts into a durable work queue. It distinguishes defects from enhancements, connects incidents to recent changes, preserves issue history, and routes work according to scope and risk.
Agents are well suited to classification and evidence gathering. Operators take over when the issue affects money, identity, external systems, contractual commitments, or architecture.
5. Documentation and training
Documentation reduces key-person system risk and grounds every other layer. The minimum useful set normally includes an architecture map, data-flow notes, deployment instructions, recovery procedures, and user-facing workflow documentation.
Documentation should be checked against the system, not treated as a one-time writing project. A change that alters a workflow, dependency, or operating procedure creates a documentation task in the same workstream.
6. Security
The security layer covers identity, least-privilege access, secrets, dependency exposure, patching, audit trails, and anomaly review. It also defines which actions an agent may take automatically and which require approval.
The important distinction is between detection and authority. An agent can identify a leaked credential or vulnerable dependency. Credential rotation, access removal, and production patching still need controls that account for downstream effects.
7. Business continuity and disaster recovery
This layer establishes what must be backed up, how restoration works, and which recovery objectives match the business. A backup record is not enough; the restore procedure and its last successful test are the evidence that matters.
Recovery work is especially suitable for scheduled verification. Agents can check backup jobs, run bounded restore tests, compare expected artifacts, and escalate failures with the evidence attached.
8. Governance
Governance defines fit, scope, risk boundaries, escalation rules, and the minimum hardening required before recurring Software Ops begins. This layer stays operator-led because those decisions depend on business context and accountability.
An agent may assemble the evidence for a fit decision. A named person decides whether Keepstone should operate the system and what conditions must be met first.
The operating evidence behind the model
The framework was designed by operators with experience across the full software lifecycle, not from a diagram alone.
- Kapil Bindal built and ran a development agency for 8 years and led engineering on dozens of shipped systems across professional services, insurance, and healthcare operations. He owns the framework's subagents, skills, and guardrails.
- James Simmons has served on the executive teams of 3 exited companies, founded or co-founded 4 startups, and works as a fractional CTO and Partner in the CTO Practice at Fortium Partners. He leads engagement and governance at Keepstone.
- Justin Simmons ran an outsourced development shop and focuses on observability, deployment pipelines, and platform-specific agent skills.
Those biographies are published on Keepstone's about page and James's author page. They establish the experience behind the model. They do not substitute for account-level performance data.
Keepstone does not yet publish a benchmark for autonomous remediation rate, escalation rate, or time to resolution. Until a measured sample is large enough and approved for publication, those figures should not be inferred from the framework description.
What agents can do without pretending risk disappeared
A useful boundary is based on consequence and reversibility, not on whether an agent technically can complete the task.
| Work type | Agent role | Operator role |
|---|---|---|
| Uptime or error detection | Monitor and correlate signals | Set thresholds and review material incidents |
| Documentation drift | Propose or apply bounded updates | Resolve business-rule ambiguity |
| Dependency updates | Prepare changes and run checks | Approve higher-risk or breaking upgrades |
| Low-risk defect | Diagnose, patch, test, and open a reviewable change | Review when scope or confidence crosses the guardrail |
| Production incident | Gather evidence and execute approved runbooks | Own decisions with business consequences |
| Architecture or fit | Assemble facts and options | Decide and remain accountable |
This is the framework's central control: volume can be automated without automating accountability.
What the client owns
The client owns the application and the work product created around it: source code, infrastructure configuration, documentation, credentials, dashboards, and deployment pipelines. Keepstone operates inside client-controlled accounts rather than moving the system into a proprietary hosting environment.
The Software Ops Agent Framework remains Keepstone's operating system. If the engagement ends, the agent layer comes off, while the hardened application and operating artifacts stay with the client. The current service model and security commitments describe those boundaries in more detail.
How a system enters the framework
A running system does not become framework-compatible by attaching an agent to it. The sequence is:
- Assess the current state. Inventory ownership, architecture, access, deployment, observability, security, documentation, and recovery.
- Identify operating gaps. Separate immediate risk from work that can wait.
- Harden the system. Bring the required layers to a written baseline without changing the URL, stack, or business logic unnecessarily.
- Set agent boundaries. Define which actions are read-only, reviewable, reversible, or operator-only.
- Operate and verify. Monitor the system, maintain the evidence, test recovery, and review value and risk over time.
The right starting point for an existing system is a free assessment. The output is a written view of what is already operable, what needs hardening, and what recurring ownership would require.
The framework is not the replacement for an operator. It is how a small number of accountable operators can apply the same operating discipline repeatedly without turning every client system into a one-off manual job.