DEV Community: Oren Melamed

From Goldfish to Elephant: Scaling AI Agent Memory for Teams 🧠

Oren Melamed — Fri, 11 Apr 2025 14:55:25 +0000

CoPilot’s Memory Bank can seriously boost productivity—when it knows your context.
But what happens when you work in a team? This post dives into the challenge of shared memory, its limitations, and why solving it might change how we build software with agents forever.

I’ve been using the Memory Bank extensively when working with the CoPilot Agent—especially inside VS Code, where I adopted Cline’s Memory Bank prompt.

The boost in quality when the Agent has this context is incredible.
But what I find really challenging is figuring out how this scales to a full dev team working on the same repo.
The Memory Bank tracks my work—which is necessarily (at least partially) different from the rest of the team’s work.

Whoever cracks this will unlock a wild new way for teams to collaborate with Agents.
I’m seeing others asking similar questions, and there are already some discussions happening in Cline’s repo around this.

It got me thinking—not just about how to manage this—but how to actually leverage it in powerful ways.

🧱 The Limits of Memory Bank Today

It’s flat. It only tracks the current and last state.
Most guides show it as a set of markdown files in the repo.
The content is transient—changes aren’t tracked over time.

But that markdown is valuable.
If we could capture the evolution of the Memory Bank over time, we’d gain a timeline of how the Agent contributed and what decisions were made.

🕰️ What If the Agent Had Historical Context?

Imagine this:
The Agent is about to make a change. Right now, it only sees the current memory state. But with access to past memory states, it could reason about:

Why a certain architectural choice was made
Which direction the project is evolving
What not to undo, even if the code “looks better” without it

This could completely eliminate cases where the Agent:

Repeats past mistakes
Reverts meaningful changes
Misses context that the team already processed weeks ago

🚀 Where This Could Go

A version-controlled Memory Bank (git-backed or otherwise)
Memory diffing tools for teams
Shared team-level memory overlays
Time-traveling Agent sessions

Curious to hear what others are doing around this.
Have you tried syncing Memory Bank across a team? Did it work?
Have ideas for making Agents more historically aware?

Let’s discuss 👇

Reimagine Software Development: How AI Agents and Deep Context Are Transforming The Future

Oren Melamed — Wed, 09 Apr 2025 12:07:03 +0000

I’ve got this vision for an exciting future where AI agents collaborate seamlessly, creating a dynamic workflow in development.

Imagine This Scenario

You ask your Agent to pull a Jira Epic and all its User Stories directly into the chat. The Agent, equipped with deep knowledge of your project through its Memory Bank, analyzes the requirements. It retrieves and presents a comprehensive analysis, including the current state and previous revisions that led to architectural decisions.

Enter the AI Agent Architect

The Agent then communicates, via the Model Context Protocol (MCP), with the company’s AI Agent Architect. This Architect Agent considers the entire system architecture, data flow, infrastructures, databases, and message queues. It either approves the plan or provides feedback for adjustments. If more information is needed, it can consult another Repo Agent through MCP to refine the solution.

Agents Collaborating for Optimal Solutions

These Agents interact until they devise the most efficient solution for the system. If the change is local to the repo, the initiating Agent executes it, relying on a system that evaluates changes globally.

Unlocking Efficiency

This approach promises significant time savings, reduced errors, and smooth workflow between teams. Even if we stop at presenting the plan to humans, imagine the efficiency of starting discussions with a ready-to-go work plan, rather than ending meetings with action items for further research.

Looking Ahead

We can also explore scenarios involving simultaneous changes across multiple repos, version management, and how this integrates with DevOps MCP for managed deployments up to production. Why stop there? The Release Agent collaborates with the Product Agent to generate release notes sent directly to clients.

The future is wild! 

If terms like Memory Bank or MCP are new to you, check out the links to learn more and enjoy!

MCP: https://www.anthropic.com/news/model-context-protocol
Memory Bank: https://cline.bot/blog/memory-bank-how-to-make-cline-an-ai-agent-that-never-forgets

How do you envision the future?

Stop Waiting, Start Building: My Practical Dive into GitHub Copilot Agent Mode

Oren Melamed — Thu, 03 Apr 2025 12:04:23 +0000

INTRODUCTION & MOTIVATION (“THE WHY”)

I'm reading and seeing many guides for agentic flows using windsurf_ai, cursor_ai, cline, and roo_code. But for some reason, Copilot agent mode in VS Code remains quite silent. I’ll guess it’s because it’s still in beta and requires installing VS Code Insiders. I’m here to share a bit of my experience with it and, more importantly, why I chose to experiment with it.

Let’s start first with The Why—why not just use the others? They are fine choices and might even be better; I'm not here to compare today. My organization already owns a GitHub enterprise account and has GitHub Copilot available for every developer, which makes it an easy choice. Going through the hassles of a new vendor, compliance, and onboarding is a headache, and I want to start now.

The Why Why

I’m also a big fan of AI and want to see how it can help my organization’s engineering team—improving DX, producing better code, better docs, better test coverage, better pipeline management, better time to resolution… basically better everything. I do, however, need to convince my team: people will say it might be buggy, or that they tried GitHub Chat or Edits mode and didn’t like it. I get that, and I admit my initial results weren’t great either—like any skill or tool, you have to practice. But I think it’s worth it. There’s a cliché that says: “AI won’t take your job; a person using AI better than you will take your job,” and that resonates with me real well.

INITIAL EXPERIENCE & EXPERIMENTATION

I first heard of GitHub Copilot Agent mode a few weeks ago when GitHub announced it, so I immediately downloaded VS Code Insiders for a test drive.

Note: VS Code Insiders updates nightly, so things can shift or break at any given moment.

Sure enough, the UI changed from time to time or permissions broke in a way that required me to act, but that’s acceptable for beta. Initially, the Copilot extension had two tabs (chat mode, edits mode), and agent mode was integrated under “edits.” You had a dropdown to switch between Edit mode and Agent mode next to the send button. The latest UI merges chat and edits in one tab, letting you toggle among “ask,” “edit,” and “agent.” This fresh UX is convenient and unlocks advanced workflows, where you plan in "ask" mode and execute in either "edit" or "agent" without loosing the scope.

First Experiment

Before tackling real issues, I wanted to see how Copilot Agent mode compared to the hyped experiences in other tools. At this point, I was as novice as one can get—just me and an input box. I asked the Agent to create a simple front-end/back-end project with some tech stack requirements. It planned out a project template, asked if I wanted to implement it, then created files, directories, ran terminal commands (at which point it paused to confirm permission), and fixed any issues it ran into on the fly. Within tens of seconds, I had a fully functional boilerplate project.

I was amazed, not because it invented some grand new app, but because it did everything in such a short time. Then I pushed it further to craft a small part of my organization’s app—saving data in Neo4j, building a FastAPI server, and a React front-end to display relationships in a graph-like manner. It automatically pulled and installed Neo, built and ran Docker, tested cypher queries, created endpoints, spun up a React app—the works. I was basically vibe coding at this point, and it felt awesome.

DEEPER DIVE INTO AGENT MODE CAPABILITIES

What really intrigued me about “Agent mode” is the ability to plan, create multiple files or directories, run (and confirm) terminal commands, and then iterate when hitting issues. It’s more than just code completion or chat-like help; it’s a continuous collaboration partner that tries to solve your entire scenario rather than insert code in a single file.

At the time of writing, switching among different Copilot “modes” (ask, edit, agent) is done through the new consolidated interface. This flexibility mirrors what I see in other AI tools: a chat-like approach, an inline edit approach, and an agentic approach for higher-level tasks—just within GitHub Copilot.

REAL-WORLD USAGE & EXAMPLES

After my initial vibe coding with toys, I wanted to prove it could solve an actual problem in my dev org. So I took a few Jira tasks from our support queue, opened the relevant projects in VS Code, gave the agent the Jira ticket, and asked it to analyze the issue and provide an RCA (root cause analysis). It proceeded to analyze code paths, ask itself follow-up questions, propose possible solutions, and, in many cases, it did a solid job. Even when off the mark, it was impressively close.

Now I was convinced, so I looked for a real feature to implement with it. Sure enough, I was seeing success, and wanted others to share in that experience.

CHANGE MANAGEMENT & TEAM ADOPTION

I decided it was too good to keep to myself. I started spreading the news and showing people how to enable Agent mode. The feedback was and still is amazing. Some folks said it saved them a lot of time, or taught them new ways to do tasks. Others struggled with longer sessions or unclear prompts. Overall, though, it was a big morale and productivity boost.

Changing how people work is never simple. There will be skeptics, or those who used it once and got suboptimal results. As with any tool, you have to invest a bit of time practicing. But if you can demonstrate it solving real Jira tickets or implementing features quickly, people usually come around.

ADVANCED USAGE (PROMPT ENGINEERING, CUSTOM INSTRUCTIONS, CONTEXT MANAGEMENT)

Prompt Engineering

Prompt engineering is crucial. If the Agent doesn’t understand exactly what you need, it’ll plan based on incomplete or incorrect assumptions. That’s why I suggest explaining your goal clearly, possibly with constraints, and asking it to plan or verify things before you just say “implement.”
Explaining your aim clearly and with the proper constraints and asking to plan before execution will bring you faster to the result then going YOLO and asking the agent to immediately go implement

Custom Instructions

Think of custom instructions like onboarding a junior dev who doesn’t know your code style or internal guidelines. With GitHub Copilot, you can store instructions in your user/workspace settings, or even in a file like .github/copilot-instructions.md that copilot defaults to try and read. This way, the Agent won’t wander off into solutions that break your codebase’s conventions or adopt new libraries randomly. You can define style rules, naming conventions, comments, etc., so the AI knows how your org typically does things.


"github.copilot.chat.codeGeneration.instructions": [

 { "text": "Always add a comment: 'Generated by Copilot'." },

 { "text": "In TypeScript always use underscore for private field names." },

 { "file": "code-style.md" }

]

Managing the Context Window

Token limitations become a problem in long sessions. The Agent can lose track of the main plan or which files have changed. A strategy is to maintain a “source of truth” in a .md file, saving your high-level design decisions, requirements, or PRD/DR as you go. Then you can prompt the Agent to reference that file. It’s essentially the memory-bank approach that tools like cline adopt systematically. Even if you don’t use a separate tool, you can replicate that logic with Copilot by consistently updating a single “master plan” file any time you refine tasks.
I highly recommend reading Cline's article about their memory bank and reading the prompt!!!

Using MCPs

Model Context Protocol aka MCP is a new standard by Antropic, the people behind Claude, that allows tools to be discovered and used by any Agent that supports the protocol, and by the time of this article I think most Agents support it already.
By having a standard way of adding any tool you can basically extend the Agent to access and use remote and up to date data sources and tools which are also after the model cut off.
VS Code insiders already has great support for installing and using MCPs which IMHO is superior to the other Agent tools out there.

CONCLUSION & FUTURE OUTLOOK

Right now, GitHub Copilot Agent mode is still in beta, but from my experience it’s already a game-changer. In just a few weeks, I went from curiosity to solving real world challanges, generating PRs, and teaching my team to adopt agentic flows.

Time savings: Quick project setups, automated troubleshooting, and immediate feedback loops.
Better adoption: Once my colleagues saw it solving real-world issues, they embraced it.
Ongoing learning: Prompt engineering, custom instructions, and context management take practice, but each improvement yields better outcomes.

I’m excited to see how GitHub Copilot Agent mode evolves once it’s officially out of beta. I suspect more advanced features, improved context handling, and possibly an even simpler user experience for new devs. For now, I suggest you give it a shot if you’re already paying for GitHub Copilot—no additional vendor or compliance overhead, just jump in and start experimenting. Happy coding, and may the Agent be with you!
Keep me posted in the comments about your experience with Github Copilot Agent mode.

Navigating the Multi-Platform Maze: Engineering Challenges Unraveled

Oren Melamed — Tue, 06 Feb 2024 11:47:18 +0000

One of the products we build at Kaltura is an OTT streaming white-label solution that enables telco operators to reach a broad audience with their TV streaming service.

One of the challenges a telco operator may face when trying to reach a broad audience is the need to have a multi-platform solution that allows consumers to watch video in their own comfort and time. This may be at home in the living room, watching video on their big screen TV, in their rooms with an iPad or on-the-go while traveling via their mobile device.

In this post, I’ll look at the challenges a team might encounter when building a multi-platform product. If you’re going to build a team that’s going to build a multi-platform product, this post is for you!

Fragmented Ecosystems: Managing Diverse Platforms

So obviously, there are many challenges a team or an individual might encounter when building a multi-platform product. To name a few:

Diverse skill sets

Developing for multiple platforms, such as iOS, Android, and web, often requires different programming languages, frameworks, and tools. This means that developers need to possess a diverse set of skills or be willing to learn multiple technologies. Managing a team with varying expertise levels and ensuring effective knowledge sharing can be a managerial challenge.

Platform-specific considerations

Each platform has its own unique set of design guidelines, user experience expectations, performance characteristics, and technical limitations. Developers need to understand these platform-specific considerations and adapt their code and design accordingly. This requires coordination and collaboration within the team to ensure consistent and optimal experiences across platforms.

Increased complexity and maintenance

Developing for multiple platforms adds complexity to the process. Each platform may have different APIs, libraries, and features, which need to be implemented and maintained separately. This increases the overall development effort, as developers need to handle platform-specific bugs, updates, and compatibility issues. From a managerial standpoint, it requires careful planning, resource allocation, and coordination to handle these complexities effectively.

Development and deployment processes

Different platforms may have different development and deployment processes. Coordinating the release cycles, versioning, and updates across platforms can be demanding. Managing the release timelines, coordinating bug fixes and feature updates, and ensuring a smooth deployment process requires effective project management and coordination within the team.

How To Survive Fragmented Ecosystems: Managing Diverse Platforms

When we started thinking about how we would build this product, we tried to imagine the key points that would have the greatest effect on the team.

The two that came to mind were the tech stack and the internal structure of the team.

Fortunately, there are various options to address multi and cross-platform apps, like React Native and Flutter, which are two good options. Even fully-fledged native development per platform could be a solution, depending on the product requirement.

Native solution — we didn’t go down this path, as it didn’t provide us with tools to share code between platforms and move team members between platforms according to necessity.

Flutter — the team decided back when we started (more than 2 years ago) that it was not mature enough and didn’t have support for tvOS.

The tech stack we eventually chose was React for web and smart TVs, and React Native for Apple TV, Android TV, tablets and mobile devices.

Back in the day, when we started the project, we reviewed the different tech stack options. We came to the conclusion that React and React Native were adjacent enough to provide us with internal sourcing between FE teams. They were also mature enough and had a good community around them to be reliable choices with a long lifetime of support.

The internal structure we chose for the project was 4 FE teams, one for web browsers, one for Smart TVs, one for Apple TV, Android TV, and tablets and mobile devices (from now on, I’ll address them as RN, short for React Native), and one core team to build the shared logic that would be used across all 3 Platform FE teams.

This structure was decided to support the business requirements of shipping different platforms at different times. Having a dedicated team per platform promised that each team could advance independently, and also be able to have per-platform-specific expertise, such as video streaming, which has its quirks on each platform.

Look at me now: What we achieved and learned along the way

Overall, the above structure and tech stack brought us to the production stage with hundreds of thousands of households consuming TV services, each with multiple devices using different platforms.

Among the lessons learned, I’ll share a few, some specific to our chosen structure and some general considerations that need to be taken in mind when coming to build such a product development team:

Avoid bottlenecks, think ahead

The core team’s role is to provide infra and API to all teams, and they are sometimes faced with different dates when a specific platform develops and ships. This means the core team needs to think ahead of how data is consumed in an optimized way between different platforms, each with its own unique constraints (mainly memory related).

Utilizing team resources in the best way possible

One contender when we chose a mixed React and React Native solution was a library called react-native-web, which enables writing with React Native syntax (, , etc.), but compiles to web target. At the time that the project started, it was in its initial stage, and we opted out of going that way. If we were to start a project today with the same requirements, we would definitely research going with a React Native-only project and have react-native-web to compile the web targets (web and smart TVs) too.
This decision has a major effect on the possible structure of the team and its required expertise.

To expand on the above point, there is also good potential in using Expo to eliminate some of the requirements needed to set up the project for native platforms for iOS and Android. It has little support for tvOS out-of-the-box to this date, but hopefully, this is coming soon…

The art of building a multi-platform engineering team

Building a successful multi-platform engineering team is truly an art, requiring a delicate balance of diverse expertise, effective collaboration, and adaptability.

There are various ways to structure your team to handle multi-platform FE development. You will need to find the one most appropriate to your team’s skill level, maturity and size, among a handful of additional considerations.

In Kaltura, we carefully organized the team to align with the unique demands of this product, considering the impact of our chosen technical stack on this decision. Moreover, we recognized that had we commenced this project today, we could have explored alternative options, taking advantage of the existing solutions now at our disposal.

I hope the points shared in this post will help you in your decision-making.

Image by rawpixel.com on Freepik