AI incident investigation architecture
Availability: available
Mendry keeps a neutral Agent Harness inside one Go backend rather than creating a workflow service or business-specific second loop. The repository still has independently buildable backend, frontend, and documentation packages.
Harness layers
Section titled “Harness layers”| Layer | Ownership | Exclusions |
|---|---|---|
agentcore/domain |
Event, Run, Tool, Invocation, Artifact, Profile, provider/executor/storage ports | No incident, project, account, HTTP, database, Redis, or provider SDK dependency |
agentcore/application |
Bounded Runner, model acceptance, paired history, registries, policy, completion evaluators | No credential lookup, transport, persistence implementation, or incident protocol |
| Adapters and composition | Provider protocols, MCP/tool clients, credentials, persistence, event ingress, rendering/delivery | Cannot let event/model data replace trusted bindings, effects, policy, or completion code |
| Scenario application | Incident evidence gates, lifecycle, checkpoints, review projection; future non-code workflows | Does not own generic model/tool stepping |
The foundation layer is implemented and focused-tested. Concrete Local, Service, and Product delivery remains separately gated.
Shared execution flow
Section titled “Shared execution flow”- Composition chooses a trusted Profile, policy, provider, tools, and
RunStore. - Runner loads the durable run, paired history, calls, and artifacts.
- Profile prepares the next model turn; policy filters the advertised catalog.
- The model response is accepted only after protocol and tool validation.
- Policy runs again for each dispatch; invocation intent is persisted first.
- Tools execute sequentially; result and artifact batches persist atomically.
- Tool observations return to paired history, or completion is evaluated.
- Terminal, waiting, cancellation, and budget reasons remain inspectable.
Delivery modes
Section titled “Delivery modes”- Foundation: implemented source contracts and shared mechanics.
- Local: runnable account-free source composition with durable file snapshots, inspection, resume, operator resolution, and bounded MCP examples; no supported binary or compatibility guarantee.
- Service: planned generic event acceptance, PostgreSQL run storage, claims, cancellation, and APIs.
- Product: planned generic run/call/artifact views.
- Incident application: existing project/single-login application, incrementally sharing foundation mechanics.
These modes share boundaries; they are not all currently released. See product status.
Incident compatibility
Section titled “Incident compatibility”The browser console and current Go API still serve the incident application. PostgreSQL holds its business state and Redis holds revocable login sessions. Signed webhooks create project-owned observations, incident ingestion groups signals, and the remediation coordinator owns evidence gates and review states.
Remediation provider calls cross the shared ModelStep, and history uses shared
pairing mechanics. The coordinator has not been replaced by the generic Runner:
incident states, tool routing, checkpoints, evidence, budgets, and human-review
semantics remain in the remediation module. People continue to control merge,
deployment, rollback, and recovery conclusions in that scenario.