Agentic investigation platform · 2026
ATR
An engineering investigation system that brings ticket context, code, data, and telemetry into a durable trace. Its action paths remain separate from diagnosis, with explicit review and team permissions.
Role & context
- Contribution
- Investigation flow, team workspaces, durable state, and guarded action paths.
- Setting
- Internal engineering system at PeopleStrong · 2026
- Public scope
- Public architecture summary. Customer tickets, repositories, and operational records are not published here.
The problem
Support issues rarely live in one place. Useful context may be spread across the ticket, source code, data, telemetry, product configuration, and team knowledge. Different teams also have different levels of access, so one fixed investigation path does not fit everyone.
A closer look
When the repository graph outgrew a single payload
- Constraint
- Production-scale graph payloads exposed memory and string-size limits. Persisting and combining all repository context as one large value was no longer a dependable path.
- Decision
- Khalid changed persistence to per-repository storage and a bounded streaming merge. The unit of storage became a repository, rather than an ever-growing combined payload.
- Tradeoff
- That choice moves complexity into merge and persistence boundaries, but avoids requiring the complete graph to fit into a single in-memory string.
- Evidence boundary
- The storage redesign is described at an architectural level. Before-and-after resource benchmarks are not published here.
What Khalid built
Khalid designed a specialist investigation flow covering analysis, qualification, reproduction, configuration checks, runtime evidence, response review, guarded coding, and code review.
He built capability-aware workspaces so a team receives only the sources, tools, models, skills, and write permissions available to it.
Autonomous runs and the engineering console share the same durable investigation trace, allowing a person to continue from the actual state rather than a loose summary.
The path from diagnosis to action is deliberately separate: writable workspaces are isolated, diffs are reviewed, and actions pass explicit team gates.
After production-scale graph payloads exposed memory and string-size limits, he changed persistence to per-repository storage with a bounded streaming merge.
Public architecture
Explore the architecture
- Issue intake
A support issue enters with the context that is safe to expose to the investigation.
- Team context
High-level product and team guidance narrows the search without embedding proprietary instructions in the public view.
- Evidence adapters
Read-oriented adapters gather relevant source, data, and telemetry signals. Exact integrations are intentionally abstracted.
- Investigation
Specialist stages compare hypotheses against evidence and keep intermediate findings in a durable trace.
- Review gate
A separate review step checks whether the conclusion is supported and whether confidence is justified.
- Human handoff
An engineer can continue from the same investigation state, with the useful evidence already attached.
- Guarded action
When action is allowed, it crosses a separate permission boundary with isolation and review.
Public abstraction. Proprietary implementation details are omitted.
Design decisions
Variable capabilities
The investigation changes when a team lacks a data source or tool instead of pretending every environment is identical.
Durable investigation state
Delegated work, evidence, and conversation state are retained so recovery and human continuation are practical.
Evidence before conclusion
The reasoning layer is fed by read-oriented evidence sources and an independent review step before a final diagnosis.
Separate action boundary
Any write path is treated as a different trust boundary with its own isolation, review, and permission checks.
Evidence & limits
Inspectable investigation, controlled action
Capability-aware execution, retained evidence, human continuation, and a separate write boundary make the investigation inspectable. Diagnostic effectiveness is a separate evaluation question: it requires reviewed ticket outcomes rather than counts of agents or successful tool calls. Outcome rates are not published in this case.
Takeaway
The strongest lesson from ATR has been that the model is only one component. Reliability comes from the execution layer around it: state, evidence, permissions, recovery, and a clean handoff to people.