GitAgent by Lyzr - Your repository becomes your agent
by•
Your AI agent's soul belongs in Git, not locked inside a framework. GitAgent is an open standard that extracts your agent's config, logic, tools, and memory into a portable, version-controlled definition. Define once. Run anywhere. Claude, OpenAI, CrewAI, OpenClaw, you name it. Same repo, any runtime. Roll back prompts like code. Branch, review, reproduce. #OwnYourAgent
Replies
Lyzr
Hey PH! 👋
We built GitAgent because the agent ecosystem was a mess — and three problems kept showing up everywhere:
① No single source of truth Everyone had agents, nobody had a canonical place they lived. Built in Claude Code? Stuck there. Move to CrewAI? Start over. Every tool, its own format, its own lock-in.
② Portability was half-solved Tons of solutions for sharing agent skills — but nobody was solving portability for the entire agent. Memory, identity, behavior — all stranded in whatever tool you built it in.
③ No real versioning No branching, no rollback, no diffing. You'd tweak a prompt, break something, and have no idea how to get back. Agents had no git — and they desperately needed it.
So we asked a simple question: what if the agent just lived in git? Every developer already knows how to fork, branch, PR, and tag. Git already solves versioning, collaboration, and portability for code.
We just mapped that onto agents.
GitAgent is our answer to all three — one repo, one source of truth, runs anywhere from Claude to CrewAI to OpenClaw without reformatting a single file.
Try it right now — run any agent directly from GitHub:
Swap -a claude for -a openai, -a crewai, or -a openclaw — same repo, any runtime. Would love to hear what runtimes you want us to support next! 🚀
Support the project: https://github.com/open-gitagent/gitagent
Support projects built on GitAgent Standard
Clawless: https://github.com/open-gitagent/clawless
GitClaw: https://github.com/open-gitagent/gitclaw
Interesting approach. Using the repo itself as the agent's memory makes way more sense than dumping everything into a system prompt or building separate context management.
How does it handle large monorepos though? Any filtering or scoping so the agent doesn't drown in irrelevant code? Also wondering about private repos, is there a self-hosted option?
Congrats on the launch, gonna try this on a couple of our projects.
Lyzr
@mihir_kanzariya Yes — we’re actively working towards full mono-repo support. If you check gitagent.sh, we already have an initial pattern in place.
It works with any self-hosted GitLab or Bitbucket setup as well, since the underlying principle is Git.
Also, if you’re building a public agent project, feel free to publish it on our registry: https://registry.gitagent.sh
GitAgent by Lyzr
Hey Product Hunt! 👋
We're thrilled to share something we've been obsessing over. @GitAgent
Here's the backstory: We kept seeing the same problem over and over again. Teams would pour weeks into building AI agents, defining tool chains, decision logic, memory, persona, only to realize that all of that IP was trapped inside whatever framework they chose on day one.
Want to switch frameworks? Rewrite everything. Want to version-control your agent the way you version-control your code? No clean way to do it. Want to hand off your agent to another team or deploy it somewhere else? Pain.
We thought, why can't agents work like code? Store them in Git. Version them. Port them. Run them anywhere.
That's GitAgent.
It extracts the "soul" of your agent. The config, logic, tools, everything that makes it yours. It stores it as a portable, version-controlled definition. Then you deploy it to any framework with one command.
We're calling this #OwnYourAgents because we genuinely believe that if you built the agent, you should own it. Not the framework. Not the platform. You.
We'd love your feedback, your upvotes, and most importantly, your honest takes on what we can do better. This is just the beginning.
Let's make agent portability the standard. 🙌
curious how GitAgent decides which parts of the repo are relevant context for a given task. do you embed the whole codebase or is there a smarter chunking/indexing step? I ask because I built a tool that does code security analysis on vibe-coded repos and the context selection is probably the hardest part to get right.
Lyzr
@mykola_kondratiuk GitAgent mainly is a standard and a tool that converts any git repo built on the git agent standard into claude code agent, openclaw agent, cursor agent, gemini cli agent etc.
So context selection is done by your agent which you select GitAgent is a all in one converter.
I hope that answers your question : )
that makes sense - so GitAgent handles the structural conversion and the context intelligence stays in whichever agent runtime you pick. clever separation of concerns. does it work with any repo or does the codebase need to be structured a certain way first?
Lyzr
@mykola_kondratiuk it has to be structured in the gitagent format but best part is if you go on the website and run the first cmd in your terminal it launches architect agent in claude code which will help you convert your existing agent into gitagent
using Claude Code to convert itself into the format is a nice touch. will try it on one of my repos.
Finally - someone built the thing I've been duct-taping together with cron jobs and prayer. The idea of turning your actual repo into an agent that understands your architecture patterns feels like the natural evolution of "docs that nobody reads" to "docs that actually do something when you're not looking.
How does it handle the inevitable drift between what the agent thinks your code does versus what it actually does after six months of "temporary" fixes?
Trufflow
The segregation of duties aspect is interesting. Are there ways that GitAgent helps enforce that or remind me to improve SOD when any one agent begins to take on too many steps within one process?