The command accepted a string. That was all. A string enclosed in quotes, passed as an argument to agate suggest, written to a file in the .ai/ directory where the agents would find it on their next pass.
A hint. A nudge. A whisper from the human to the machine.
Jay discovered it on a Friday when Agate was midway through sprint two of a logging aggregator. The first sprint had produced a working pipeline, but the error handling was thin—bare if err != nil { return err } patterns scattered through the code like someone had copy-pasted from a tutorial. The assessment had flagged it. Sprint two was supposed to fix it.
But the agents were heading in a different direction. They were refactoring the pipeline architecture instead, adding a channel-based fan-out pattern that was elegant but unnecessary. The error handling was still thin. The agents were solving a problem that didn't exist instead of the problem that did.
Jay typed:
agate suggest "Focus on error handling first. Wrap errors with context using fmt.Errorf. Add structured logging for each error path."
He hit Enter. The suggestion was recorded. Agate's next step picked it up.
The change was immediate. The agent abandoned the fan-out refactor and turned its attention to the error paths. Within twenty minutes, every return err in the codebase had been replaced with return fmt.Errorf("operation %s: %w", name, err). Structured log statements appeared at every error branch. The error handling went from thin to thorough in a single pass.
"Does it always listen?" Navan asked, watching over Jay's shoulder.
"Usually," Jay said. "The suggestion gets injected into the agent's context for the next step. It's not a command. It's a suggestion. The agent weighs it against the current plan and the assessment results."
"So it could ignore you."
"In theory. In practice, the suggestions I've given have been pretty specific. 'Focus on error handling first' doesn't leave a lot of room for interpretation."
Navan tried one on his own project, a protocol validator that was generating overly verbose test output. He typed: agate suggest "Reduce test output verbosity. Only print failures and a summary line."
The next step trimmed the test output to exactly what he'd described. Failures and a summary. Nothing else.
"It's like pair programming," Navan said, "except your partner has the patience of a saint and the memory of a database."
Jay shook his head. "It's not pair programming. Pair programming is two people solving a problem together. This is one person giving directions and the machine executing. It's more like... being a navigator. You see the map. They drive. Sometimes you say 'turn left here' and they turn left."
"And sometimes they don't," Navan said.
"And sometimes they don't. But usually they do."
The fact that Jay's first suggest was about error handling tells you everything about what kind of engineer he is. SREs always see the error paths first.