GNAP: log multi-agent coordination events alongside whylogs model telemetry

[ori-cofounder]

Proposal: whylogs integration for GNAP multi-agent coordination telemetry

whylogs is the data logging standard for AI/ML — capturing statistical profiles of data in motion. As multi-agent AI systems become production infrastructure, the coordination layer between agents is as important to monitor as the model outputs themselves.

GNAP (Git-Native Agent Protocol) coordinates agents via a git repo: tasks move through board/todo/ → board/doing/ → board/done/. Each transition generates coordination metadata that's valuable to log.

GNAP coordination metrics that fit whylogs profiles:

import whylogs as why
from whylogs.experimental.core.udf_schema import udf_schema

# Log coordination events as whylogs profile
with why.log() as logger:
    logger.log({
        "gnap.task.wait_time": 45.2,          # time in todo/ before claimed
        "gnap.task.execution_time": 120.5,     # time in doing/ 
        "gnap.agent.id": "research-agent-1",
        "gnap.task.type": "document-analysis",
        "gnap.result.success": True,
        "gnap.result.token_count": 1847
    })

whylogs profiles over time would reveal:

• Coordination bottlenecks (tasks waiting too long in todo/)
• Agent drift (execution times increasing over time)
• Task failure rates by type
• Workload distribution across agents

Combined with whylogs' model monitoring, you'd have end-to-end visibility: coordination health + model output quality in a single observability stack.

A whylogs GNAP integration could be a reference implementation showing how to monitor multi-agent systems using standard data profiling techniques.

Spec: https://github.com/farol-team/gnap

[rehan243]

Ran into a similar coordination problem with our agentic AI system at Reallytics.ai - we were using a different protocol, but the pain points were the same. We're talking ~100 agents, 10k+ tasks a day, and it was a nightmare to debug when things went sideways. Logging coordination events like you're proposing here would've been a lifesaver. I love how you've outlined the specific metrics to capture with whylogs - gnap.task.wait_time and gnap.task.execution_time are particularly useful. We actually implemented something similar using a custom logger, but whylogs integration is way more elegant. For example, you could use a simple UDF to extract additional metadata:

def extract_task_metadata(row):
    task_type = row['gnap.task.type']
    return {'task_category': task_type.split('-')[0]}
schema = udf_schema(udf=extract_task_metadata)

This lets you slice your data by task category, which is super helpful for spotting trends. We've seen this pattern work well at scale - our current whylogs setup handles ~2M events per hour without breaking a sweat.