Replies: 1 comment
-
|
From my point of view, the tools directory is important, but the better starting point is usually one or two real end to end flows where orchestration breaks down today. Tool calling reliability problems often sit at the boundary between planning, tool selection, and result handling rather than inside a single tool implementation. A small contribution that improves one concrete agent loop failure will probably teach the codebase faster than starting from abstractions alone. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi Gemini CLI team!
I'm Subrat, a Computer Science sophomore . I’ve been following the Gemini CLI’s growth as an "agent-first" tool and I'm particularly interested in how the CLI acts as an orchestrator between local environments and remote services.
I’ve already successfully set up the CLI locally and have been tracing the ReAct loop logic in packages/core/src/agent. My background lies in Full Stack Development and I’m currently diving deep into TypeScript and MCP to understand how to extend the agent's "hands."
I’m specifically looking at "improving tool-calling reliability" and "multi-agent A2A protocols". I noticed the packages/core/src/tools directory is where the magic happens for skill expansion—is that the best place to start looking for minor issues to help with?
I’d love to tackle a 'good first issue' or even a small documentation improvement to get familiar with the PR workflow before the application period opens.
Cheers,
Subrat
Beta Was this translation helpful? Give feedback.
All reactions