{"slug": "llm-free-multi-agent-memory-architecture-how-to-build-real-team-memory-with-jira", "title": "LLM-Free Multi-Agent Memory Architecture: How to Build Real Team Memory with Jira + GitHub + Commit Log", "summary": "A developer has built an LLM-free multi-agent memory architecture that connects Jira, GitHub, and commit logs to solve team memory loss in software projects. The system uses a relational and graph-based memory store with specialized agents—ContextAgent, ExpertiseAgent, and RiskAgent—to answer questions about code decisions, file risk levels, and developer expertise without relying on large language models. The architecture provides verifiable, evidence-based answers by linking issues to pull requests, commits, and file changes, avoiding the hallucination and inconsistency risks of LLM-centric approaches.", "body_md": "One of the biggest problems in software teams is not writing code. Code eventually gets written, refactored, tested, and deployed. The real challenge, most of the time, is this:\n\n\"Why was this decision made?\"\n\nWhen a developer joins a project, they can't understand the work just by looking at the repository. They can see the code, but not the story behind it. Why was a service split this way? Why is an interface designed so oddly? Why does a test specifically check that edge case? Why has a file turned into something everyone is afraid to touch? The answers to these questions usually lie not in the code itself, but in the team's history.\n\nThat history is scattered across different tools:\n\nThat's why, for a new developer, the learning process usually goes like this:\n\n```\nLook at the code → Find something you don't understand → Search Jira → Search PR → Search Slack → Ask the old developer → Repeat\n```\n\nThis is team memory loss. And this loss costs time, causes errors, and exhausts people.\n\nWhen a well-structured team memory system is in place, it should be able to answer questions like:\n\nWhat these questions have in common: the answers are not in a single record. The answers are hidden in relationships.\n\nFor example, to answer \"who knows the auth module?\" it's not enough to just count commits. You need to look at all of these together:\n\nSo team memory is essentially a relationship problem.\n\nLLMs are powerful, but it's not always right to put an LLM at the core of every problem. For systems like team memory, the main requirements are:\n\nLet me also add a personal note here. Even though I write a series about AI-free life on Dev.to, this time I specifically wanted to write something on the software engineering side without AI as well. Honestly, the motivation behind this article is partly to push myself outside of repetition while also giving you some food for thought: You can build quite useful, technically clean, and maintainable systems without tying every problem to an LLM.\n\nLet me be even more direct: we're a bit tired of it. Constant AI, constant agents, constant RAG, constant prompts. These are certainly valuable topics, but sometimes you just want to see solid, old-school engineering. This article was written with exactly that motivation.\n\nAn LLM-centric approach carries several risks.\n\nAn LLM might behave as if there's a relationship between an issue and a commit when no such relationship exists in the real system. Pointing to the wrong PR, showing the wrong person as an expert, or misinterpreting a past bug fix causes serious time loss.\n\nIn team memory, answers should not be \"educated guesses.\" Answers must come with evidence.\n\nIf a system says \"this file is risky,\" it should be able to explain why:\n\n```\nsrc/auth/token_service.py changed 18 times in the last 90 days.\n5 of those changes are linked to bug fixes.\n4 different developers have touched the file.\nA race condition was discussed in the last two PRs.\nThe test file was not updated at the same rate.\n```\n\nThis kind of answer is debatable, verifiable, and improvable. An LLM saying \"it looked risky to me\" doesn't deliver the same quality.\n\nLLMs are not needed for questions like:\n\nThese are pure data queries. SQL or graph traversal solves them instantly.\n\nFor team memory, the same question should always produce the same answer on the same data. LLM-based systems can give different answers each time. This is unacceptable for audit and debugging.\n\nThe foundation of the system is a memory store. This store holds the following:\n\nOn top of this, agents query the memory store, score it, and produce explainable outputs.\n\nThe basic flow:\n\n```\nJira / GitHub / Git\n    ↓\nIngestion Layer\n    ↓\nMemory Store (relational + graph)\n    ↓\nAgents (ContextAgent, ExpertiseAgent, RiskAgent, ...)\n    ↓\nExplainable Output (CLI / API / Bot)\nPROJ-1247 issue\n  → linked to PR #382\n  → resolved by commits f00ba47 and b91c0de\n  → changed src/auth/token_service.py\n  → contributed by Mehmet Turac and Ayşe Demir\n  → reviewed by Burak Kaya\n```\n\nWith this information, a new developer no longer has to search randomly.\n\nI'm not using the word \"agent\" in the LLM agent sense here. In this architecture, an agent is:\n\nA small service with a specific task, which queries memory, makes rule-based decisions, and produces evidence-backed output.\n\nSo what we call an agent is not a bot running prompts. It's a perfectly classical software component.\n\nExtracts context for an issue, PR, or file.\n\nCalculates the most knowledgeable people for a file or component.\n\nFinds risky files based on signals like high churn, bug fixes, and contributor spread.\n\nSuggests suitable reviewer candidates for a new PR.\n\nFor a new developer on a given component, lists the most valuable issues and PRs to read.\n\nReports data quality problems in the memory store.\n\nEach agent works with a scoring and rule-based logic.\n\nThe minimum entity set for the first version is:\n\n```\nDeveloper\nRepository\nIssue\nCommit\nFile\nPullRequest\nReview\nIssueComment\n```\n\nEven with this model, a powerful memory system can be built.\n\nA developer can appear with different identities across systems:\n\nThese need to be linked to a single developer record.\n\nCommits are among the most reliable events in the system. Hash, message, date, author, and changed files are stored.\n\nFiles should be stored not just as paths, but with component information.\n\nFor example:\n\n```\nsrc/auth/**      → auth\nsrc/payment/**   → payment\ninfra/**         → infra\n```\n\nIssues give us business context. Summary, status, priority, type, component, and timestamps are stored.\n\nPRs show us how a change was discussed within the team. Reviewers, changed files, linked issues, and commits are among the key fields.\n\n```\nCREATE TABLE developers (...);\nCREATE TABLE repositories (...);\nCREATE TABLE issues (...);\nCREATE TABLE files (...);\nCREATE TABLE commits (...);\nCREATE TABLE commit_files (...);\nCREATE TABLE commit_issues (...);\nCREATE TABLE pull_requests (...);\nCREATE TABLE pr_commits (...);\nCREATE TABLE pr_files (...);\nCREATE TABLE pr_issues (...);\nCREATE TABLE reviews (...);\nCREATE TABLE issue_comments (...);\n```\n\nThese tables represent graph thinking in a relational model. Join tables like `commit_files`\n\n, `commit_issues`\n\n, `pr_files`\n\n, `pr_issues`\n\nserve as relationships.\n\nWhen finding an expert for a file, looking only at commit count can be misleading. So the score can be calculated as follows:\n\n```\nexpertise_score =\n    commit_count * 10\n  + review_count * 8\n  + issue_comment_count * 2\n  + churn / 20\n  + recency_bonus\n```\n\nThis score is not an absolute truth; it's a ranking signal. What matters is that the score is explainable.\n\nBad output:\n\n```\nAyşe is an expert on this topic.\n```\n\nGood output:\n\n```\nAyşe made 5 commits in this file recently, reviewed 3 PRs,\nlast activity was 2026-05-20, and total churn value is 320.\n```\n\nExplainable signals are needed for risk too:\n\n```\nrisk_score =\n    churn\n  + bug_count * 100\n  + contributor_count * 25\n  + commit_count * 5\n```\n\nThis is a simple starting point. In production, signals like test coverage, incidents, revert commits, deployment failures, and code ownership can be added.\n\nA new developer picks up issue `PROJ-1247`\n\n.\n\nThey run this from the CLI:\n\n```\nteammemory issue-context PROJ-1247\n```\n\nThe system produces:\n\n```\nIssue: PROJ-1247\nSummary: Token refresh race condition\nStatus: In Progress\nPriority: High\nComponent: auth\n\nRelated PRs:\n- #382 Fix token refresh race condition [merged]\n\nCommits:\n- f00ba47 Mehmet Turac — PROJ-1247 guard token refresh with per-session lock\n- b91c0de Ayşe Demir — PROJ-1247 add regression test for refresh race\n\nChanged files:\n- src/auth/token_service.py\n- src/auth/session_manager.py\n- tests/auth/test_token_refresh.py\n\nPeople in context:\n- Mehmet Turac\n- Ayşe Demir\n- Burak Kaya\n```\n\nThis output was generated without an LLM. Because everything is based on relationships in the database.\n\nThen the developer wants to see file experts:\n\n```\nteammemory file-experts src/auth/token_service.py\n```\n\nOutput:\n\n```\nExperts for src/auth/token_service.py\n\n1. Ayşe Demir — score 92.0\n   commits: 4, reviews: 2, comments: 1, churn: 430, last activity: 2026-05-20\n\n2. Mehmet Turac — score 80.5\n   commits: 3, reviews: 1, comments: 2, churn: 390, last activity: 2026-05-18\n```\n\nThis answer too is not a guess — it's a calculated signal.\n\nThe success of this system depends on data quality. If commit messages don't contain issue keys, PR descriptions are empty, or issues aren't linked to the right components, the team memory stays incomplete.\n\nThat's why HygieneAgent is critically important.\n\nWhat it reports:\n\nThis report is not a blame tool — it's a tool for improving memory.\n\nThe demo runs with SQLite. The recommended structure for production:\n\n```\nPostgreSQL = raw event store, audit, checkpoint, agent outputs\nNeo4j/AGE   = relationship analysis and traversal\nFastAPI     = controlled access layer\nCLI/Bot     = developer workflow integration\n```\n\nThings to pay attention to in production:\n\nIdentity resolution is especially important. If the same person appears as `mehmet@example.com`\n\nin Git, `mturac`\n\non GitHub, and `Mehmet Turac`\n\nin Jira, all of these need to be linked to a single developer record.\n\nThese limitations are not flaws. On the contrary, they are the system's honesty. It doesn't make things up when it doesn't know.\n\nThe main idea of this article is simple:\n\nFirst build the data model correctly for team memory. Don't rush to LLMs.\n\nJira, GitHub, and Git already give us an incredibly valuable event history. If we correctly link this history, we can produce reliable answers to questions like:\n\nIn this system, answers don't come with \"the model thought so.\" Answers come from commit, issue, PR, and review records.\n\nSometimes the best engineering is not using the most impressive technology; it's correctly scoping the problem and building a simpler, more reliable, and more explainable solution.\n\nAnd this repo is trying to show exactly that:\n\n```\nNo LLM.\nNo RAG.\nNo prompt.\nNo embedding.\n\nThere is data.\nThere are relationships.\nThere are rules.\nThere is evidence.\n```\n\n**TeamMemory LLM’siz**, yazılım ekipleri için Jira + GitHub + Git commit loglarından çalışan, tamamen deterministik bir takım hafızası örneğidir.\n\nBu repo özellikle şunu göstermek için hazırlandı:\n\nHer takım hafızası problemi LLM, RAG, embedding, prompt veya agentic workflow gerektirmez. Bazen doğru veri modeli, iyi ingestion, sağlam sorgular ve küçük deterministik agent’lar daha güvenilir sonuç verir.\n\nBu örnekte **LLM yoktur**.\n\nRAG yoktur.\n\nVector database yoktur.\n\nPrompt yoktur.\n\nModel çağrısı yoktur.\n\nBunun yerine:\n\nvardır.\n\n```\ncd teammemory-llmsiz\npython -m venv .venv\nsource .venv/bin/activate\npython -m pip install -e .[api,dev]\n\nteammemory init-db --reset\nteammemory seed\nteammemory issue-context PROJ-1247\nteammemory file-experts src/auth/token_service.py\nteammemory component-risk auth\nteammemory onboarding auth\nteammemory review-suggest 382\nteammemory hygiene\n```\n\nAPI çalıştırmak için:\n\n```\nuvicorn teammemory.api:app --reload\n```\n\nÖrnek endpoint’ler:\n\n```\ncurl http://127.0.0.1:8000/issues/PROJ-1247/context\ncurl \"http://127.0.0.1:8000/files/experts?path=src/auth/token_service.py\"\ncurl http://127.0.0.1:8000/components/auth/risk\n```\n\n…", "url": "https://wpnews.pro/news/llm-free-multi-agent-memory-architecture-how-to-build-real-team-memory-with-jira", "canonical_source": "https://dev.to/turacthethinker/llm-free-multi-agent-memory-architecture-how-to-build-real-team-memory-with-jira-github-commit-dpa", "published_at": "2026-06-05 11:03:01+00:00", "updated_at": "2026-06-05 11:42:53.168178+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-infrastructure", "large-language-models", "mlops"], "entities": ["Jira", "GitHub", "Slack"], "alternates": {"html": "https://wpnews.pro/news/llm-free-multi-agent-memory-architecture-how-to-build-real-team-memory-with-jira", "markdown": "https://wpnews.pro/news/llm-free-multi-agent-memory-architecture-how-to-build-real-team-memory-with-jira.md", "text": "https://wpnews.pro/news/llm-free-multi-agent-memory-architecture-how-to-build-real-team-memory-with-jira.txt", "jsonld": "https://wpnews.pro/news/llm-free-multi-agent-memory-architecture-how-to-build-real-team-memory-with-jira.jsonld"}}