Skip to content

Feature: Support AGENTS.md for agent instruction configuration #10

@STRRL

Description

@STRRL

Summary

Currently, the eino ADK agent's behavior is entirely hardcoded in buildSystemPrompt() (pkg/analyzer/analyzer.go). There is no way to customize or extend the agent's instructions without modifying Go source code.

Motivation

Google recently introduced the AGENTS.md convention as a standard way to provide instructions to AI agents — similar to how CLAUDE.md, CURSORRULES, or COPILOT-INSTRUCTIONS.md guide coding assistants. The idea is that a project can include an AGENTS.md file (or per-directory variants) that agents automatically discover and follow.

Supporting this convention in lapp would:

  1. Make agent behavior configurable without recompilation — users could tweak analysis instructions, add domain-specific guidance, or customize output format by editing a markdown file.
  2. Enable per-project customization — different log sources (Kubernetes, application servers, CI pipelines) benefit from different analysis strategies. An AGENTS.md in the workspace could provide context-specific hints.
  3. Align with the emerging ecosystem convention — as more tools adopt AGENTS.md, supporting it makes lapp interoperable and familiar.

Proposed Behavior

  1. When building the agent, check for an AGENTS.md file in the workspace directory (and optionally the project root).
  2. If found, append its contents to the system prompt (after the hardcoded base instructions).
  3. Support a flag like --agents-md <path> to explicitly specify the file.
  4. The hardcoded buildSystemPrompt() remains the default — AGENTS.md is purely additive.

Example

<!-- AGENTS.md -->
# Log Analysis Guidelines

- This project uses structured JSON logging via Zap.
- The `trace_id` field links related log entries across services.
- Ignore `health_check` endpoint logs — they are noise.
- When reporting errors, always include the `request_id` for correlation.

The agent would then incorporate these hints when analyzing logs from this project.

Alternatives Considered

  • Environment variables / CLI flags for each option: Does not scale well for rich, structured instructions.
  • Config file (YAML/TOML): Less expressive than markdown for free-form guidance; also less aligned with the emerging convention.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions