What Counts as Evidence

PentAGI can record a great deal of activity, but a large record is not automatically strong evidence. This chapter maps one material finding backward from a Task report to the Subtask, agent decision, tool call, output, screenshot, memory entry, and telemetry around it. The goal is a practical review standard: understand what each record proves, what summaries and external services change, and why the repository's proposed cryptographic evidence chain must not be confused with the current audit trail.

One action appears in several kinds of record

When an agent calls a tool, PentAGI does more than return a string to the model. The custom executor validates the JSON arguments, creates an observation for the tool or delegated agent, records a tool-call row, writes a message log when the call has a user-facing message, invokes the handler, sanitizes the returned text, updates status and duration, and may store an eligible result in vector memory. Different tool categories receive different observation semantics: a direct environment or search tool is not the same kind of event as an agent delegation or a barrier that changes Flow state.

The result is a layered record. A terminal log can show the command input and output associated with a container. A search log can identify an engine, query, and returned result. An agent log can show that the Primary Agent delegated a question to a specialist and what came back. A message log shows the model-facing exchange. A tool-call row records function, arguments, status, duration, and result. A screenshot record can preserve visual evidence from browser activity. A vector-store log records retrieval or storage operations. These layers overlap, but they answer different questions. A reviewer should resist counting records as if more rows automatically meant more genuinely independent confirmation: the same model output may be copied into a message, a tool-call result, a memory chunk, and a telemetry event. The value comes from the relationships between records and from the raw observation beneath them, not repetition alone.

sequenceDiagram participant A as Agent participant E as Executor participant T as Tool / container participant L as Operational logs participant M as Memory store participant O as OTel / Langfuse participant R as Reporter participant V as Reviewer A->>E: Emit typed tool call E->>L: Record call and message context E->>O: Start tool / agent observation E->>T: Execute action T-->>E: Return output or error E->>L: Update status, duration, and result E->>M: Store eligible result with scope metadata E->>O: End observation with output E-->>A: Return chain response A->>R: Provide completed Subtask result R-->>V: Produce Task report V->>L: Trace claim to action and output

This multiplicity is useful because no single representation is sufficient for every review. The live chain needs a compact response that the next model call can consume. The tool-call row needs execution status and timing. A terminal or search log needs operational detail.