[Proposal] Gryph Actions

[abhisek]

Background

Gryph currently consist of a simple ETL system. It does the following:

1. Get into the AI Coding agent loop using hooks (must be supported by the Agent)
2. Transform agent specific hook schema to Gryph's own internal data model
3. Store the events emitted by AI coding agents into a local sqlite database

It currently has some plumbing commands like log and query to view and filter on this data. Both log and query operate on a human friendly view of the data and not on the raw event. This decision was taken entirely to retain control over DevEx and so that it can evolve independently of the core data model and data pipeline in Gryph.

For raw events, we have introduced export which serializes events into a JSON object with a verifiable JSON schema for machine consumption. The export command can be used to compose actions ie. chain gryph export .. with jq and other tools for custom use-cases.

Gap

Gryph is currently a storage for AI coding agent event data and visualization of data. It does not allow taking action. Some of the possible use-cases for taking action:

1. Notify user if AI coding agents did something that they care about (eg. executing curl)
2. Block an action that violates a given policy
3. Inject custom guidance for AI Coding agents when certain condition matches (similar to what Anthropic's default hooks work)

We have already thought about [2] and [3] and considered a security layer as part of the architecture. This layer will provide security plugins to response with a decision with additional metadata such as reason, guidance etc. Gryph, while handling hook will respond to the agent based on this security decision.

However, we do not have an ability to trigger an external action. It is like "hook" for hooks, with Gryph acting as the translator for AI Coding agent hook schema. So just by providing a hook interface doesn't really solve much because the same can be achieved directly by installing hooks at AI Coding agent level.

Proposal

While I was in favour of introducing a new concept called Action for Gryph, which would use simple patterns to evaluate an event and take an action, but I believe it doesn't make sense because the same can be achieved with Gryph's export composability.

Example: Raise an alert on the local system if Gryph executed a specific command during last 2h

gryph export --since 1d | \
jq -r 'select(.action_type == "command_exec" and (.payload.command | startswith("go build"))) | .payload.command' | \
while read -r cmd; do osascript -e "display notification \"$cmd\" with title \"gryph: curl detected\""; done

I think we should leverage Gryph's JSON export to compose custom actions using well known tools.

[anantshri]

my 2 paisa's.

For post facto analysis this is good to have export and based on that some action. However there are two things to keep in mind

1. Purely awareness: while people are using these tools they are sometimes too deep in so many tabs that they may not have a clear picture of what autonomous systems are doing.
2. trust breach notification : if i have been clear with agent to not use xyz tool or only use abc tool then if a trust is breached for one or the other reason a notification immediately vs 2 hours later makes a huge difference.

[Rul1an]

This export-first direction makes sense to me.

The useful split, at least from the outside, is live action handling vs a small durable review artifact. Gryph can keep the hook path fast and developer-friendly, while gryph export becomes the place where another tool can safely consume what happened without depending on the SQLite layout or the human log view.

That is close to the boundary we have been trying to hold in Assay: observed external outcome -> small receipt -> verifiable bundle -> reviewable claim/diff surface. Not asking Gryph to own that layer, and not asking for an integration. The interesting bit is whether Gryph wants one stable external event shape that downstream tools can test against.

If so, the smallest row I would look for is something like:

agent/run id, event id, action type, timestamp, subject or target when known, command/tool name, args hash or redaction marker, result hash or error, and policy decision metadata when Gryph has one.

A privacy-safe JSON fixture would probably be enough. It would let downstream consumers prove they understand the boundary without turning Gryph into an evidence-spec project.