We have normalized waiting 3k to 5k milliseconds for a computer to respond. In the world of distributed systems, that is an eternity. If your Postgres query took 4 seconds, you would fire your DBA. But because it’s “Gen AI” we kinda accept it.

Well maybe we shouldn’t.

As we move from “chatbots” to autonomous agents that execute multi-step reasoning loops, latency isn’t just a UX annoyance but it would eventually become a compounding tax on performance. If an agent needs five “thoughts” to solve a problem, and each thought takes 2 seconds, your user is now waiting 10 seconds for a basic output. That is non-viable software.

The right solution might not be GPT-6/7 or Claude AGI etc. The solution potentially is rethinking the internal architecture. It’s about realizing that 40-60% of the queries hitting the expensive inference endpoint are semantically identical to queries you answered yesterday.

This is Semantic Caching.

The failure of the exact match (hash-based caching)

In traditional web development, caching is trivial. You take a request say GET /product/123, you hash it, and you store the payload in Redis. If the hash matches, you serve the data. O(1) complexity. Fast.

This fails strictly in NLP because human language is high-entropy.

• User A: “How do I change my password?”

• User B: “I need to update my login credentials.”

• User C: “Password reset steps.”

To a standard SHA-256 hash, these are three distinct keys. You will pay for three separate inference calls to generate the exact same semantic response.

To solve this, we move from lexical matching (exact text) to semantic matching (intent).

The architecture: vectors and similarity

Semantic caching relies on vector embeddings. Before your user’s query ever touches an LLM, it should pass through an embedding model (like OpenAI’s text-embedding-3-small or a local HuggingFace model like all-MiniLM-L6-v2).

This model compresses the “meaning” of the input text into a fixed-size vector (a list of floats).

Instead of doing a key-value lookup, we perform a vector search (specifically, Approximate Nearest Neighbor or ANN) against our cache database. We represent the new query as a vector in multi-dimensional space and ask the database: “What other vectors are located within a specific radius of this one?”

If we find a vector that is “close enough,” we don’t generate a new answer. We return the stored completion associated with that neighbor.

The engineering challenge: Precision vs. Recall

This is where it gets technical and where most implementations fail. It is not binary. It is probabilistic.

You define “closeness” using a distance metric, usually Cosine Similarity (measuring the angle between vectors) or Euclidean Distance.

You must define a Similarity Threshold. This is a hyperparameter you have to tune.

• Threshold too loose (e.g. 0.7): You get high recall (lots of cache hits), but low precision. The user asks “How do I delete my account?” and the cache matches it with “How do I edit my account?” because they are semantically close. The user gets the wrong instructions. This is a catastrophic failure.

• Threshold too tight (e.g. 0.99): You get high precision, but the cache rarely triggers. You are back to paying for redundant compute.

The 2-pass system

To run this in production without serving garbage answers, you cannot rely solely on a single cosine similarity check. You need a ranking logic.

1. The Retrieval Step (Fast):

Use a bi-encoder (standard embedding model) to retrieve the top 5 candidates from your Vector DB based on a generous threshold. This is extremely fast because bi-encoders map sentences to independent vectors.

2. The Re-ranking Step (Accurate):

Pass the user’s query and the potential cached question into a Cross-Encoder.

A cross-encoder processes both inputs simultaneously. It pays attention to the interaction between the two sentences. It outputs a score from 0 to 1 indicating how much sentence A entails sentence B.

• Bi-encoder: “Apple” and “Orange” are close (both fruit).

• Cross-encoder: “Can I eat an apple?” vs “Can I eat an orange?” -> High similarity. “I hate apples” vs “I love apples” -> Low semantic alignment for response reuse.

This second step adds latency (maybe 50ms) but it increases your Cache Precision dramatically.

LLM validation

If you are operating in a high-risk vertical (fintech, health), even a cross-encoder might feel too risky.

You can implement an LLM Validator. When you get a cache hit, before serving it to the user, you send a prompt to a smaller, faster model (like a distilled Llama 3 or GPT-3.5):

“User asked: [New Query]. Cached question was: [Old Query]. Does the answer to the cached question satisfy the new query? Reply YES or NO.”

This is still faster and cheaper than generating a full reasoning response from a frontier model like Gemini 3, but it provides a semantic safety rail.

Why this matters for agents

We are entering the era of Agentic workflows. Agents are recursive.

An agent tasked with “Analyze this competitor’s pricing” might break that down into 10 sub-steps. Three of those steps might be generic queries it has performed a hundred times before for other clients.

Without a semantic cache, the agent re-derives first principles every single time. It is slow, and it is expensive.

With a semantic cache, the agent acts as if it has Long-Term Memory. It “remembers” it solved a similar sub-problem 10 minutes ago, or 10 days ago. It retrieves the result instantly and moves to the next step.

This is how you build agents that feel “smart” and responsive. You minimize the cognitive load on the LLM by offloading memory to the cache.

The metrics that matter

Do not just track “Hit Rate.” That is a vanity metric. You need to instrument:

1. Latency Savings: (Avg Inference Time) - (Avg Cache Retrieval Time).

2. False Positive Rate: How often did a user reject or downvote a cached response?

3. Cache Recall: Of all the queries that could have been cached, how many did we actually catch?

Closing thoughts

Stepping back a bit, it’s helpful to look at this from first principles.

The user doesn’t care about your parameter count. They don’t care if you’re using a mixture-of-experts model or a quantized 7B parameter local model. They care about the interaction loop. Latency is friction, and friction kills the magic of Software 3.0.

Right now running a raw LLM application is a bit like having a human re-derive the laws of physics every time they want to catch a ball. It’s a massive waste of cognitive compute. Semantic caching effectively gives your AI a “System 1” mode of thinking that is fast, instinctive, and cheap while reserving the expensive “System 2” (the actual LLM inference) only for novel, complex problems that actually require reasoning.

We are moving away from the era where “it works” is the benchmark.

We are moving into the optimization phase. We are taking O(n) compute costs where costs scale linearly with usage and collapsing them toward O(1) efficiency for redundant tasks.

If you want to build agents that can actually run in the real world without burning a hole in your GPU budget or your user’s patience, you really need this layer.

Build the cache. Save the compute. make your agents fast.

— Dhrubajyoti
Product @ Harness

It happens right at the beginning. You have an insight, you have data, and you have a vision. You write a PRD, create some rough wireframes, and present it to your team. Everyone accepts & says they understand.

But they don’t. Not precisely.

The designer imagines a specific interaction pattern. The engineering lead mentally starts architecting a database schema based on an assumption you didn’t mean to imply. The stakeholders starts to picture a feature set twice as large as the one you described.

Traditionally, we tried to fix this with more documentation. We wrote longer specs, held more alignment meetings, and created more detailed tickets. We tried to legislate clarity into existence.

Over the last few months, I’ve stopped doing that. I have fundamentally changed how I start products. Instead of documents, I now start with AI generated prototypes.

V0 for interfaces and Claude Code for logic. I have moved from writing about products to building these working prototypes before I set up the kickoff meeting.

This isn’t about doing the engineer's job. It’s about respecting their time by bringing them a validated reality rather than a vague hypothesis.

In this post I try to capture the playbook I used at Harness to adopt an AI-first approach to product design & delivery.

The problem with “Imagined” software

The traditional kickoff meeting usually centers on a “blank page” problem & the “Interpretation Gap” stage as I mentioned earlier.

Disconnect exists but we usually don’t discover these until weeks later, during the first design review or, worse, the first staging build. By then, time has been wasted.

The solution is to stop describing the product and start showing it.

Start with V0/Bolt/Lovable

Describing a user interface in text is incredibly inefficient. This is where generative UI services like V0 helps. V0 allows me to bypass the “lo-fi wireframe” stage entirely. Instead of drawing boxes on excildraw, I prompt the system with my intent.

This is highly useful for PMs who do not have prior experience with writing code or are not highly technical in terms of understanding code or generate code driven prototypes.

Why this matters: It creates an immediate “Straw Man.” It is rarely perfect. The padding might be wrong, the color contrast might be off, or the information hierarchy might be strange. But it is tangible.

When I put this screen in front of a team, the feedback changes from abstract to concrete:

• “That chart takes up too much vertical space.”

• “We are missing a user profile entry in the sidebar.”

• “The ‘Done column needs a collapse state.”

We no longer debate philosophy but we really start to critique the product.

Claude Code: The logic layer

If V0 provides the skin, Claude Code provides the nervous system.

This is the phase where most PMs would probably hesitate, but it is also where the highest value exists. A V0 generation looks good, but it fails to build functional / logical experiences in most scenarios. To truly validate a product idea, you really need to test the behavior.

Claude Code acts as an agentic interface that runs in your terminal. It allows you to manipulate the code without needing to really know the exact code.

The workflow: Once I have the V0 design, I usually pull it into a local environment and use Claude Code to customize the logic.

• “Make the ‘In Progress’ column sortable by date.”

• “What happens if the user tries to drag a ‘Done’ item back to ‘Draft’? Add a confirmation modal.”

• “Simulate a data delay so I can see what the loading state looks like.”

This allows me to answer functional questions that usually stall development later on. I do not assume how the sort function might work, but I start to use it.

A new PM skillset

This shift necessitates a change in how we view the PM skillset.

For years, we have debated whether PMs need to be technical. In this AI-first model, the answer is yes but with a caveat. You do not need to be an engineer. You do not need to know how to optimize database shards or manage memory.

But you must be able to read and reason about code.

You need to look at the artifact Claude produced and understand:

• How are we handling edge cases?

• What is the logic flow for an error state?

If you can read code, these systems give you significant leverage.

If you cannot, you will struggle to direct the AI effectively. The modern PM needs to be “code-conversational,” capable of inspecting the mechanics of the product they own.

My playbook

1) Choose a baseline (production screenshot or Figma frame)

Start with something real: a production screenshot or a well-structured Figma frame gives the AI an anchor. This helps with component recognition and gives you a clear “source of truth” to generalize from.

Why: The model maps components more accurately from a high-fidelity reference than from a vague description.

2) Component-first extraction (prompt the model)

Tell the tool to analyze the image/frame for repeatable components and build a component library first and not just to generate a single page.

Key instruction: “Identify component candidates, output a component list with props, and generate a minimal component library before composing the page.”

Why: A component-first approach yields artifacts that are reusable and maintainable, which makes later engineering adoption far easier.

3) Generate an initial prototype composition

Have the model recompose the screen from the generated component library. This gives you a working structure and identifies mismatches quickly.

4) Iterate using two parallel loops

• Prompt-based iteration: Change layout, swap icons, or alter labels using prompts. Useful for quick experiments (e.g. “Make filters vertical on desktop, horizontal on mobile”).

• Code-based iteration (Optional): Open the generated files and move DOM nodes, adjust flexbox and Tailwind classes, add new components for missing bits. This is where you get from “close” to “useful”.

Why both loops: Prompts are fast for large changes while code edits ensure structural correctness and predictable behavior.

5) Try sketches selectively (and simplify)

You can feed sketches into the model, but keep them simple and zone-focused. Avoid overloading a sketch with micro-details as the model interprets simple zones (header, left-nav, primary content, right pane) far more reliably.

6) Map well-structured Figma (using MCP server) to components

If you have an organized Figma file (good layer names, components, variables), point the model at that frame and instruct it to implement using your prototype components.

Tip: The more consistent your Figma naming / tokens, the fewer surprises you’ll see in the generated code.

7) Add mocked data & states

Wire up fake fetch calls, loading states, and empty/error states. That is where product behaviors reveal themselves and you can test edge cases with real interactions.

8) Share live preview early and iterate with stakeholders

Send a sandbox link to design, engineering, and product marketing. Ask them to try common flows and give concrete feedback and they’ll return actionable items rather than vague “looks fine.”

9) Validate with customers (if appropriate)

Use the prototype in discovery calls or usability sessions. Watch where people hesitate, what labels confuse them, and which controls they ignore.

Why this is better for the business

At the company level, moving from documents to working prototypes reduces waste.

Faster Alignment A prototype forces decisions. You cannot hide behind vague language in a coded interface. The button either works or it doesn’t. This forces stakeholders to align on specific functionality days or weeks earlier than usual.

Better Customer Conversations Showing a customer a PDF and asking “Would you use this?” yields polite, unreliable data. Letting a customer click through a live prototype yields actual behavioral data. You learn where they get stuck and what they ignore.

Risk Mitigation The biggest risk in product development is building the wrong thing. By prototyping the logic early, we expose the complexity before we commit expensive engineering resources to the final build.

Final thoughts

We are moving away from an era where PMs were judged by the length and clarity of their documents. We are entering an era where PMs are judged by the clarity of their prototypes.

AI is not replacing the product manager. It is removing the administrative friction that sits between having an idea and seeing that idea function.

If you’re a PM on enterprise SaaS and are even moderately comfortable reading or editing code, this will become table stakes. You don’t need to be an engineer. You need curiosity and a willingness to express product ideas in code even when the code is rough.

Next time you’re stuck writing a PRD to explain a UX flow or waiting a week for mocks, try prompting instead. You might be surprised how quickly your idea becomes something real.

— Dhrubajyoti
Product @ Harness.io

From a distance, DevRel can look like a sequence of well-intentioned activities. Travel. Conference talks. A steady stream of blog posts. Engaging with the community. Updating documentation. It’s easy to assume that a full calendar equals a healthy program. That assumption is comforting, but it is also wrong.

If you strip the work down to its purpose, the definition becomes straightforward. DevRel should make it easier for a developer to go from curious to productive. That is the job. Everything else is secondary. And when you evaluate DevRel through this mental model, much of the work that looks impressive at first glance turns out to have little long term value.

The observations below are patterns I see repeatedly. Each one reflects the difference between activity and impact, and what DevRel should be doing instead.

It should treat conferences as experiments, not annual commitments

Teams often feel obligated to attend a long list of conferences each year. The energy of these events can create the illusion of progress. Booths and talks give a sense of presence. But when you track outcomes, the yield is usually low. Very few conversations turn into adoption. Most talks are forgotten by the time someone leaves the venue.

A better approach is simple. DevRel should select only the events where the audience and product truly overlap, run activation experiments, and return only if the event produces qualified usage. The goal isn’t visibility. The goal is measurable impact. Everything else is optional.

It should write to remove friction, not to fill a content calendar

Content is an easy way to signal productivity. Publishing frequently looks like discipline and creates something tangible to share internally. The problem is that much of it never reaches developers at the moment they actually need it.

Writing should begin with a real problem a developer is facing. The intent should be to remove confusion, not to produce volume. High quality, targeted content almost always outperforms a high-frequency schedule. What matters is whether the writing helps a developer succeed faster.

It should build communities that function without constant intervention

Community involvement is important, but it becomes counterproductive when the DevRel team becomes the first responder for every question. This unintentionally trains the community to wait for official answers rather than helping each other.

A strong community should not depend on the DevRel team for constant engagement. The team’s job is to create the conditions for peer-to-peer support, highlight contributors, and step in only when a conversation stalls. This model scales. Constant hand-holding does not.

It should show product teams where the journey breaks

Many DevRel teams see themselves as conduits for feature requests. The intent is good, but the signal is weak. Developers frequently request features they do not ultimately use. Teams get caught in loops of opinion-based conversations that rarely lead to the right outcomes.

DevRel should focus on where the journey actually breaks. Where developers abandon onboarding. Where activation collapses. Where documentation fails. These points of friction carry far more weight than feature requests. When DevRel brings clarity instead of noise, product teams can make faster and more confident decisions.

It should track the numbers that reveal reality

It is easy to report vanity metrics: traffic, impressions, follower counts, event attendance. Internally, these numbers look positive and make teams feel productive. The issue is simple: they do not predict adoption or revenue.

DevRel should measure activation, time to first value, retention, and support deflection. These numbers are harder to move but directly tied to product success. They also expose uncomfortable truths, which is exactly why they matter.

It should avoid adding new programs until foundational issues are fixed

When DevRel feels stuck, teams often reach for new initiatives: a hackathon, a podcast, an ambassador program. These ideas can make a team feel innovative, but they rarely solve the real problem when the developer journey itself is still broken.

The more disciplined approach is to identify the single largest friction point and fix it fully before doing anything else. This kind of work is not glamorous, but it compounds. You earn more from removing one major blocker than from launching five new programs.

It should treat documentation as a critical product interface

Documentation is often maintained as an operational task. But updates alone do not translate into better adoption. Even well organized docs can fail if they ignore how developers actually behave.

Documentation should be treated as one of the core product surfaces. It should be structured around real tasks, informed by data, and revised based on where developers get stuck. This is slow, methodical work, but it pays off more consistently than almost anything else DevRel can do.

Why this matters

If you simplify DevRel to its essence, the work is not complicated. The team exists to improve the path developers take to adopt the product. It should reduce friction, increase clarity, improve activation, and support long term success.

When DevRel keeps this objective at the center, the work stops being a performance and becomes an operating function. The team focuses on outcomes, not optics. They make decisions rooted in data, not habit. And the entire company benefits from the clarity.

A question every team should ask

When the program feels disorganized or overloaded, one question cuts through noise:

If we stopped doing this for a month, would developers reach value slower?

If the answer is no, the work is nonessential.
If the answer is yes, the work is DevRel.

Most teams discover they have been doing far more nonessential work than they realized. Letting go of that work is uncomfortable, but it creates space for real impact.

Closing thoughts

DevRel should feel like a steady, durable function that strengthens the foundation developers rely on. It should not rely on charisma or constant activity. It should be intentional, data-informed, and focused on long term value.

When DevRel operates this way, it becomes part of the company’s infrastructure. You may not see it every day, but you feel the difference in how consistently developers succeed. That is what true DevRel should be doing.

— Dhrubajyoti
Product @ Harness.io

It becomes really interesting to understand why it performs this well. We obviously can’t see what’s happening inside the model but based on how it responds clearly a few consistent patterns are starting to make sense.

Reasoning before rendering

Gemini 3 consistently produces images that reflect a pre-generation reasoning step. You see this most clearly in prompts that require:

• Concept composition (e.g. an isometric robotic arm with three distinct coordinate frames)

• Spatial alignment (e.g. maintaining RGB→XYZ axis conventions across different joints)

• Multi-step geometric constraints (e.g. merging or overlaying shapes without distorting their relationships)

Where typical diffusion models often blend objects together or lose positional accuracy, Gemini 3 preserves:

• Clean separation between components

• Consistent orientation across the entire scene

  Correct relative positioning (base → joint → tool frame)

• Meaningful adherence to geometric conventions

Based on the outputs, the model behaves as if it creates a coherent layout before adding detail because the global structure remains stable across the render. This doesn’t imply any specific internal mechanism but we could understand that the final images reliably reflect the logic of the prompt rather than drifting into visual noise.

The pattern resembles what prior research like HuggingFace’s ReflectionFlow observed: introducing reasoning-like steps improves compositional integrity in complex multimodal tasks. Seeing this pattern in a production-scale model is encouraging.

The STEM visual training signal matters

A clear improvement shows up in tasks involving diagrams, plots, math figures, and other structured visuals. Most generators treat these formats as just “images.” Gemini 3 doesn’t.

I tested it on:

• multi-panel technical infographics

• annotated geometry constructions

• multivariate scatter/line plots

• nested flowcharts

• software/ML architecture diagrams

• symbolic math diagrams

Across all of these, it keeps axes straight, labels aligned, shapes consistent, and region boundaries intact. It behaves like a model that has actually seen diverse STEM diagrams during training and not like other models that are improvising from natural-image priors.

This lines up with what StructVisuals found:

• Models break when they don’t learn structural priors for STEM diagrams

• Small geometric distortions compound across edits

• Technical imagery requires different supervision than natural imagery

Gemini 3 narrows that gap. It understands, for example, that a scatter plot shouldn’t collapse into a heatmap, that component labels must stay anchored, and that flowchart lines can’t wander or cross randomly.

None of this looks like diffusion “luck.” It looks like exposure to the right data and objectives.

Consistency across variants

A subtle but important detail: Gemini 3 maintains consistency across a series of related prompts.
Examples:

• “Generate the diagram.”

• “Rotate it 90° and keep all labels in place.”

• “Remove the bottom-left component while keeping everything else fixed.”

Most diffusion models drift after each modification but Gemini 3 is noticeably more stable. The behavior suggests an internal representation that abstracts the diagram rather than storing a single image sample. For technical and research workflows, this is a meaningful step forward.

Performance on the “long-tail” prompts

I’ve accumulated a library of prompts built specifically to expose failure cases:

• Deeply compositional blueprint instructions

• Hybrid symbolic–visual queries

• Transformations involving coordinate geometry

• Nested constraints that break typical diffusion models

Gemini 3 succeeds on far more of these than expected. Not flawlessly. There are still failure modes but the success rate is high enough that it materially shifts prior assumptions about what mainstream models can handle.

The overall impression

The model feels like the result of three converging efforts:

1. A solid reasoning substrate likely trained with some form of planning traces or structured supervision.

2. Extensive multimodal STEM exposure giving the model robust priors about diagrams, charts and other structured content.

3. Improved architecture + training stability which reduces drift across variants and preserves compositional fidelity.

None of this is mysterious. This is what happens when the training data actually reflects the difficulty of the tasks we expect the model to perform.

For people who have been studying structured visual generation, the direction is not surprising but in practice, the improvements are real and substantive.
Gemini 3 is far from “solved reasoning + vision,” but the trajectory is clearly in the right direction.

— Dhrubajyoti
Product @ Harness

It was fast. It was slick. It was terrifying.

Because the more autonomy we give these systems, the more we expose ourselves and our customers to a completely new class of risk. And let’s be honest: most of us are still figuring out how to build reliable human-owned systems. Giving software the freedom to act on its own, without the right safety checks, is like handing your intern the AWS root credentials and saying, “Try not to break anything.”

If you’re a product manager, engineering leader, or security partner evaluating the use of AI agents, here’s the uncomfortable truth:

You are not deploying a smarter chatbot. You’re deploying a decision-making system with access to real infrastructure, data, and users.

This post is my attempt to help you frame that decision the right way and avoid the mistakes so many teams are on the verge of making.

What is an AI Agent really?

Before we get into the complexities of governance and security, let’s start by clarifying something fundamental: What exactly is an "AI agent"?

If you’ve been following the AI space, you’ve probably heard the term thrown around a lot. But it’s worth pausing for a moment to define what we mean when we say “AI agent.”

At its core, an AI agent is a system that exhibits three key capabilities:

• Observes: It can ingest and process external data i.e. anything from documents, APIs, to telemetry. It takes in the world around it.

• Plans: Based on that data, it then makes decisions. It can use planning frameworks like ReAct or chain-of-thought to figure out what needs to happen next.

• Acts: After processing and planning, it actually does something whether that’s writing a file, making an API call, or sending a Slack message.

But that’s just the basic setup. AI agents can also do a lot more:

• Persist memory: This means storing information like facts or insights into a vector database, enabling them to "remember" things over time.

• Use tools and plugins: Think integrations with platforms like GitHub, Jira, or Notion to improve the agent’s functionality & scope.

• Operate in a loop: The agent can improve its outputs over time, revising and adjusting its actions until it hits the desired goal.

At this stage, we’re talking about something way more powerful than just summarizing meeting notes. These agents aren’t just passive observers. They have the potential to change how systems work, manage production environments, engage with customers, or even handle large-scale infrastructure.

And here’s the catch: When we’re working with AI agents, the old product checklist of "Does it pass QA?" is no longer enough. These are systems that aren’t just running code but they’re also making decisions, executing actions, and learning from the process.

Security - The invisible blast radius

One of the hardest parts about AI agent security is that the attack surface is... everything. It’s not just the obvious stuff like prompt injection or unauthorized access — though those are very real risks. It’s that agents, by design, are built to take action. Autonomously. That’s powerful, but it also means the potential impact of a mistake or an exploit can be massive.

Let’s try to walk through some of the big security questions we need to ask when building or integrating AI agents.

Who does the Agent think it is? (Identity & Permissions)

Most agents run under a service identity or API key. But here’s the problem: we often plug them in quickly to get things working, without slowing down to ask what permissions that key actually has.

I’ve made this mistake. I’ve seen others make it too:
Giving the agent full, org-wide permissions just to move fast.

It works. Until it doesn’t.

What we should be doing instead:

• Apply the least privilege always: The agent should only access what it absolutely needs. Nothing more.

• Scope access by project, environment, and action: Read-only access for dev? Full write for a single prod service? Be deliberate.

• Create dedicated service accounts: Avoid shared keys or inherited roles. Make it clear who did what, and why.

• Rotate credentials. Monitor usage: Keys age, scopes change, and agents evolve. Don’t let access go stale.

What can it remember and where? (Data Storage & Leakage)

One of the most exciting (and risky) trends in agent design is persistent memory. Whether it’s storing documents, embeddings, or structured logs the agent’s ability to “remember” past interactions can be super helpful for personalization and efficiency.

But here’s the grey area:

That memory can become a liability fast.
It only takes one misstep for an agent to absorb sensitive info (say a customer's personal information or a secret) and then accidentally resurface it in the wrong context.

Here’s what you need to ask yourself:

• Is the agent’s memory actually secure? That means encrypted both at rest and in transit with no shortcuts.

• Do you have retention policies in place? How long should this memory live? What happens after that? Define it upfront.

• Can you inspect or purge what it remembers? If something sensitive gets stored, can you find it and remove it quickly?

• Are your vector databases treated like real data stores? Spoiler: they are real data stores. That means:

  • Schema discipline

  • Role-based access control

  • Logging and audit trails

  • Avoiding wild-west dumps of unstructured data

What happens when things go wrong? (Isolation & Fail-Safes)

Let’s be honest AI agents don’t always fail gracefully.
They don’t throw neat 500 errors or crash with a stack trace. Instead, they might:

• Get stuck in an infinite loop

• Hammer your CI/CD pipeline with nonsense requests

• Auto-close a critical customer escalation based on a bad assumption

These aren’t traditional bugs. They’re breakdowns in reasoning. And with agents, they’re not rare.

So, how do you protect your system (and your team) when the agent goes off the rails?

• Rate-limit everything. Whether the agent is hitting APIs, running jobs, or triggering workflows impose strict QPS and concurrency limits. This should be enforced at the gateway or orchestrator level.

• Use sandbox environments for testing. Use sandboxed namespaces, containers, or virtual projects with scoped credentials. Never give an experimental agent write access to production. You should be treating it like an intern on day one.

• Set timeouts and retry limits. If an agent is looping through a planner or calling external services repeatedly, use circuit breakers and fail-fast logic. No task should be allowed to consume unbounded resources.

• Add human-in-the-loop gates. Block sensitive or irreversible actions unless a person explicitly approves. You can choose to use policy engines (e.g. OPA, AWS IAM conditions) or workflow tools (e.g. Argo, Airflow) to require human sign-off before performing destructive actions.

• Log everything. Full traceability of decisions, inputs, outputs, and side effects isn’t optional. You’ll need it the moment something misfires.

Governance: Making the invisible visible

Security is about prevention. Governance is about explanation.
It’s what helps you answer the question everyone asks after something goes wrong:

“Why did this happen?”

And if your team can't answer that, then your system isn't just broken it's ungovernable.

This is the part a lot of teams skip in the rush to ship. And they always regret it later, usually when leadership, legal, or a customer is asking for answers you can’t give.

Can you explain the Agent’s behavior? (Observability)

The most basic governance question is: Why did the agent do that?

If you can’t answer that question, your system is effectively ungovernable.

You need:

• Full logs of every input, output, and tool/action invocation. That includes prompts, API calls, function executions, and any state changes the agent made. Think audit trail but for intent and action.

• Traces of the reasoning path especially for multi-step agents using planning or chain-of-thought logic. You should be able to replay how the agent arrived at a decision even if it was the wrong one.

• Dashboards that non-engineers can use. Ops, support, and compliance teams shouldn’t need to read JSON logs or trace vector math. Give them timelines, decision trees, and search filters they can actually use.

Put differently: your compliance team should be able to reconstruct an incident without knowing what a vector embedding is.

Do you know when to get a human involved? (Autonomy Modes)

Autonomy is not binary. I recommend thinking in levels:

• Level 0 – Manual: Human does everything. The agent observes, maybe logs.

• Level 1 – Assistive: Agent suggests, but a human approves. Think copilots, draft generators, or PR suggestions.

• Level 2 – Guarded Autonomy: Agent can take action, but only within strict boundaries. Maybe it can restart a service or reassign a ticket, but not delete anything or change customer data.

• Level 3 – Full Autonomy: Agent operates independently. It acts, logs, and you review the impact later.

Production environments should start at Level 1. Graduate to Level 2 only after months of observation and incident-free behavior. Treat Level 3 like launching a rocket. If it fails, there’s no undo. You need confidence, containment, and a whole lot of telemetry.

Are You Auditing and Improving Over Time?

Governance isn’t a checkbox you tick once and forget. It’s a feedback loop and it only works if you commit to running it, consistently.

Here’s the basic lifecycle:

1. The agent takes action

2. You log what happened

3. You review and audit those actions

4. You improve the agent or adjust its constraints

Skip that last step, and your agent will drift from “safe” to “unpredictable” faster than you think.

What should this look like in practice?

• Immutable audit logs, stored externally. Don’t rely on the agent’s internal memory or runtime to preserve critical history. Store logs in a secure, centralized system something your security team already trusts.

• Behavioral drift detection. Over time, agents can change due to upstream LLM updates, data shifts, or configuration changes. You need a way to track deviations in how the agent behaves across similar tasks before it causes a regression.

• Scheduled governance reviews. Block time (monthly or quarterly) to sit down with security, product, and engineering. Review incidents, trends, and any “weird” agent behavior. This is where you decide if it’s time to level up autonomy or roll it back.

The pre-prod checklist you should be using

If you’re serious about evaluating an AI agent before production, here’s a checklist I’ve used internally:

Closing thoughts

It’s easy to move fast especially when the prototype works and the results feel magical. But moving fast doesn’t protect production systems. Discipline does.

Here’s what’s worth remembering:

An AI agent isn’t just a tool. It’s a system.
It’s like hiring a new team member, one with no ethics, no intuition, and no context.
It just has access. And it moves fast.

That’s power. But it needs boundaries.

So instead of asking, “Can we automate this?”
Ask “Should this run unattended?” And if yes, why now?

When you do ship, make sure the agent is aligned, observable, and well-contained. Then let it run.

Because responsible autonomy isn’t about saying “no.”
It’s about saying “not yet” until you’re sure what you’re trusting it to do.

Curious how other orgs are building secure AI agents? I’m compiling case studies for a future post. Subscribe or drop me a note if you want to share your own lessons.

— Dhrubajyoti
Product @ Harness | Thinking about agent infrastructure, developer experience, and LLM applications.

In my first startup, we tried to sell a productivity tool for remote teams. We were convinced it was a PLG play. “Just build it, let them try it, and they’ll love it”.

We threw up a landing page, added a free trial, pushed it on Reddit and Product Hunt, and waited. People signed up. Some even used the product. But most never came back. And the ones who did? They asked for things we never intended to build—or they came from markets we never intended to serve.

It took us 2-3 months to realize: that growth is not just about distribution but more about fit. That’s when I learned this truth the hard way: PLG isn’t always the go-to-market strategy, and SLG isn’t just for enterprises. And choosing between them isn’t a binary decision — it's a strategy grounded in your product's complexity, your customer’s buying behavior, and the current stage of your product’s maturity.

In this post, we will try to break them down, figure out what actually works, and more importantly — when.

What really is PLG and SLG?

Product-Led Growth (PLG)

This is where the product does most of the heavy lifting. Users discover your product, sign up, explore its value (often via a free trial or freemium tier), and ideally convert — without ever needing to talk to sales.
Think: Notion, Figma, Calendly. Clean onboarding, intuitive UX, and clear aha moments are critical. If the product’s good, it sells itself.

You invest more in growth loops, activation, self-serve funnels, and usage-based upgrades. It's great for bottoms-up adoption and tends to start with individuals or small teams.

Sales-Led Growth (SLG)

Here, sales is the driver. Prospects usually enter through marketing or outbound outreach, then a sales team engages — running demos, navigating procurement, working through objections, negotiating pricing, etc.
Think: Salesforce, Workday, Oracle. Complex, high-ticket deals where the buyer isn’t always the end user. You optimize for lead qualification, stakeholder alignment, and enterprise requirements.

This motion typically suits products with long sales cycles, high ACVs (average contract value), or heavy customization.

Most great companies today use both

The best companies build products that sell themselves — and then add humans to help when it matters.

Take Zoom. You can sign up, host a meeting, and share a link — all within minutes. Classic PLG: fast, frictionless, and user-first. But if you’re an IT manager at a 500-person org looking for SSO, detailed analytics, or compliance features? There’s a sales team ready to walk you through procurement, security reviews, and volume pricing. That’s SLG.

Same with Slack. It started with viral, bottoms-up adoption — teams inviting each other in like wildfire. But once it hit a certain scale, the need for admin controls, integrations, and company-wide rollouts made SLG a natural layer.

Even newer players like Linear are catching on. Most users find them through word of mouth or social, but when a high-intent lead from a large team comes in, they’re not afraid to jump on a call and help close the loop.

The 0–1 phase - Everyone starts with Sales, even if they don’t admit it

Here’s the part no one puts on their launch blog:
Every early-stage product is sales-led.
It just happens to be the founder (or the first PM, or the designer-engineer duo) doing the selling.

I’ve been on teams where we added weeks into building simplified onboarding flows, user-friendly tooltips, and designing the perfect freemium dashboard.
But none of it really mattered — because we didn’t yet know what problem we were really solving or who actually cared.

So we did what works: we dropped the playbook and hit the ground.

• Picked 30 ideal customer profiles (ICPs).

• Wrote thoughtful cold emails.

• Got on Zooms.

• Did white-glove onboarding.

• Rewrote our pitch every single day based on what landed (and what didn’t).

Was it scalable? Not even close.
Did it work? Absolutely.

Because in the 0–1 phase, you don’t need scale.
You need clarity.
You need 10 users who deeply love what you’re building — not 1,000 drive-bys who never come back.

You’re not optimizing for conversions yet.
You’re optimizing for insight — and insight comes from conversations, not dashboards.

So… What should you use for your next product?

Here’s how I like to think about it:

Are you pre-product market fit? Do the unscalable things.

Seriously — you don’t “choose” between PLG or SLG at this stage. You do whatever it takes to get your first 10–20 customers across the line.

I have known companies where the CEO personally cold-emailed engineering leaders for weeks.
No marketing site. No pricing page.
Just grit.

He ran every demo. Took every call. Did follow-ups. Tweaked the pitch live.
It wasn’t scalable — but it worked. And more importantly — it gave the team a priceless signal about who cared, what resonated, and where the real pain was.

Only after that do you build your self-serve onboarding.
Only then does PLG make sense — because now, you know exactly what the product needs to show, say, and do to convert.

Early on, SLG disguised as founder-led hustle is your best friend.
It’s a forcing function to learn fast and tighten your value prop.
Once you’ve nailed your ICP and their pain, then you can scale that insight into a product-led motion that converts.

Build the engine after you know where you’re going.

Is your product easy to adopt? or Does it need hand-holding?

This is one of the first questions I ask when thinking about go-to-market strategy.

If you’re building something horizontal, intuitive, and habit-forming — PLG can work wonders.

A friend of mine recently launched an AI writing tool for recruiters. The aha moment is instant: paste a job description, hit a button, and candidates get personalized outreach. People go from trial to paid in minutes. No call. No pitch. Just product value doing the talking.

Now compare that with something like a cost optimization engine for Kubernetes clusters. You could have the cleanest UI in the world — but most DevOps teams won’t feel the value until someone walks them through how it fits into their existing setup. That’s where human guidance matters.

💡 Rule of thumb:
If a user can find value in under 10 minutes, PLG might be your wedge.
If not, lean into SLG — or a hybrid motion.

Can your product talk back? Maybe try product-led sales?

PLG works best when your product feeds signals back to your team. For example:

• Who activated?

• Who invited others?

• Who hit a usage threshold?

• Who’s stuck?

This is where things get interesting.

In a PLS model, the product still drives the initial motion — trial, freemium, self-serve. But behind the scenes, your team is watching for intent signals:
Who activated? Who invited teammates? Who’s bumping into usage limits?

And when the right signals show up — that’s when your sales team steps in.

Not with a cold pitch. But with help.

“Hey, noticed your team’s close to the user limit — want to hop on a quick call to see how we can unlock more value?”

It’s consultative. It’s human. And most importantly, it’s timely.
No cold outbound. No spam. Just value → insight → human support.

When SLG is the only way

That said, there are products where PLG alone just isn’t enough.

• Your product is complex or mission-critical.

• Time-to-value is long.

• Your buyer isn’t your user.

• You sell to enterprises with legal, compliance, and procurement gates.

Take a developer security platform. Your end users might be engineers. But your buyer is probably a CISO or a VP of Eng. They’re not going to swipe a card after a free trial. They want a demo. A whitepaper. Maybe an RFP. They want to trust the people behind the tool as much as the product itself.

This is where a classic sales-led motion shines. You need outbound, solution engineers, consultative selling — the full playbook.

But even here, a PLG mindset still helps.
Give your sales team a playground. A sandbox. A limited-feature free trial. Let prospects see some value, even if the deal still runs through procurement.

Don’t be religious. Be pragmatic.

One thing I’ve learned building and shipping products:
No one cares how you close deals — just that you do.

If your product is simple but the market is crowded, PLG helps you stand out.
It gets you in the hands of users fast, builds love, and scales reach.

If your product is complex and high-stakes, SLG gives you the structure to navigate the buying maze — from procurement to security reviews to IT handoffs.

And if you’re like most of us?
You’ll do both.

A hybrid strategy isn’t a compromise — it’s a progression.
You lead with the product. Layer in sales when signals show intent.
And evolve your motion as your customer base, product surface, and deal size grow.

Use what works. Drop what doesn’t.
That’s not a bad plan switch. That’s just good product sense.

Use this cheat sheet to guide your motion

I’ve put together a quick summary of what we’ve discussed, which can help you decide whether PLG or SLG is the best fit for your model. This cheat sheet is a simple way to check where you stand.

Closing thoughts

The next time you find yourself debating PLG vs. SLG, flip the question around.

Ask yourself:

• How does my product create value?

• How do my customers buy?

• Where does my team have leverage?

Once you have answers to those, try choosing the strategy that best supports your reality. Don’t get stuck in the analysis paralysis. PLG and SLG do not come with strict guidelines. They’re frameworks. Use both when it makes sense.

And above all, keep talking to your customers.

They’ll always show you the way.

— Dhrubajyoti
Product @ Harness | Thinking about agent infrastructure, developer experience, and LLM applications.

Rolling out new tools is hard. Rolling out AI tools that fundamentally change how developers work? Even harder.

This week, I came across a research paper that really helped put a lot of the things I’ve been noticing into perspective: "Understanding and Designing for Trust in AI-Powered Developer Tooling" the latest release from Google’s Developer Productivity for Humans series.

And here’s the key takeaway that hit home for me:

Adoption isn’t just about giving people access — it’s about trust, real workflows, team culture, and the day-to-day pain points developers actually feel. If the rollout didn’t address those, low adoption isn’t surprising — it’s a signal that there’s more work to do.

The good news: this is fixable. But it needs a different approach than just another training session or email announcement.

You gave developers smarter tools — but that’s not enough

Rolling out tools like Cursor or Windsurf seems like a no-brainer, right?

• Code suggestions get faster.

• Reviews get tighter.

• Bug fixes get surfaced earlier.

• Teams should be more productive.

On paper, it all adds up.
In reality? Developers are hesitant.
Usage doesn’t really take off immediately.
Skepticism creeps in.

And if you ask developers — really ask them — it’s usually not about disliking AI, or being resistant to change.

It’s about something much deeper: trust.

Developers don’t blindly trust new apps — and they shouldn’t

Picture a developer in a typical enterprise environment:

• They’re working in highly complex, often poorly documented, hybrid stacks.

• They’re handling customer PII and multiple services with dependent systems under tight regulatory oversight.

• They’re operating in environments where one wrong code change can trigger not just outages — but compliance breaches, audits, and career risks.

Now imagine an AI tool that promises “faster coding” and “smarter suggestions.”

The natural instinct isn’t "Awesome!" — it’s caution:

• "Does this tool actually understand the internal frameworks?"

• "Will it suggest something that breaks compliance or security?"

• "Will I be held responsible if an AI suggestion causes an incident?"

And honestly? They’re right to ask.

Because in an enterprise setting, it’s not just productivity at stake — it’s security, stability, and professional reputation.

And if an AI assistant:

• Hallucinates a bad API call,

• Suggests a method that violates SOC2 rules,

• Or autocompletes code that leaks customer data,

then trust isn’t just damaged — it’s broken, possibly for years.

Security and access are fundamental frictions

And there’s another layer: Access friction.

In enterprises, getting an AI tool rolled out isn’t just "turning it on."

• There are network restrictions and proxy issues.

• There are internal approval workflows for tool usage.

• There are security reviews that slow or block third-party integrations.

• There are IP protection concerns: "Where does the code I type go? Is it stored?"

If trying the tool feels risky or painful, adoption dies early — no matter how good the tech is.

How to start fixing the trust gap

If you’re facing low AI adoption today, here’s what you should focus on:

Find early champions, Not enforcers

Start small.
Identify developers with influence who are curious about AI — not just the most senior people, but the ones who others trust technically. Don’t force adoption top-down. Curiosity beats compliance.

Invest in white-glove onboarding for them. Help them find real wins, and let them share stories organically.

Make AI’s decision-making visible

Developers hate black boxes.
Cursor and Windsurf both have features that can surface why a suggestion was made — amplify those.
Push for features that show confidence scores, references, or traceability back to real documentation.

If your developers can say, "I see why it suggested that," you’re halfway to trust.

Customize to local context aggressively

Enterprise developers want AI that understands their stack — their private libraries, their weird config setups, their internal naming patterns.
Set up fine-tuning, embedding retrieval, or local context expansion wherever possible.
The closer the AI feels to "this was trained on our systems," the better.

Respect developer agency, Always

Cursor and Windsurf — and honestly, any good AI dev tool — let users easily accept, reject, or modify suggestions.

Hammer this home in your rollout messaging:

"You’re always in control. AI assists; it never replaces your judgment."

Nothing builds resentment faster than feeling overridden.

Invest in long-term enablement, Not a one-time launch

Adoption isn’t a light switch.
Plan for live demos, office hours, async feedback channels.

• Collect usage patterns — not to judge, but to learn.

• Treat rollout like a slow, ongoing open beta.

Iterate based on real-world feedback — not just what the vendor’s success slides say should happen.

Closing thoughts

Rolling out AI tooling across an organization is still a very new experience for most teams. It’s a trust-building exercise.

We’re still early in this journey, and we'll continue to learn as these tools gradually become a natural part of every developer’s daily workflow.

You’re not just introducing Cursor or Windsurf.
You’re introducing a new way of working where a machine becomes a true collaborator in the coding process.

That’s a huge psychological shift.
It’s messy. It’s slow. It’s deeply human.

But if you invest the time to build trust and not demand it? the payoff is massive:
Teams move faster. Code quality improves. Engineers feel empowered, not threatened.

And your AI tooling doesn’t end up as "yet another installed thing."

It becomes how real work gets done with confidence and clarity.

Thanks for reading. If you’re building in this space — or just exploring — feel free to connect with me. I’d love to hear how you’re thinking about agent systems, protocol standards, and where it’s all headed.

— Dhrubajyoti
Product @ Harness | Thinking about agent infrastructure, developer experience, and LLM applications.

You wanted to build great products. Solve real problems. Work with smart engineers. Talk to users. Ship things. Writing? That was supposed to be a side effect, not the main event.

But over time — without even realizing it — you start writing everything.

• Product specs

• Release notes.

• DevRel blogs and tutorials (if you’re in the advocacy seat).

• Engineering RFCs.

• Internal docs.

• Strategy briefs.

• Team updates.

• Twitter threads (😅)

And whether you realize it or not — you’re judged by the clarity of your words a lot more than your thoughts, or even your ideas.

Because if you can’t make it understandable, it’s as good as not said.

So that got me thinking: what actually makes writing good — especially when you’re surrounded by dev tools, APIs, and B2B software?

After spending almost 3 years into devrel, product, and just enough engineering to get myself in trouble, I’ve started to see some patterns. Here’s what I’ve learned — and a few writing hacks I keep coming back to 👇

Why does writing feel so hard?

Here’s my theory: Writing feels hard because it forces you to think clearly. No ambiguity, no vibe-checking in meetings, no shoulder taps to clarify. Just you and your thoughts on a blank page.

It exposes fuzzy ideas.

It reveals when you're not sure.

And it makes you ask: Who am I even writing this for & why?

The moment that clicked for me — the “aha” — was when I stopped asking “Is this good writing?” and started asking:

“What decision does this unblock?”

Every doc, spec, tweet, or thread exists to move something forward. It’s either helping someone learn, decide, align, or act. If it’s not doing that — it’s noise.

What makes writing "good"?

Let’s be real — writing isn’t something most of us got into this job to do. I didn’t go to college thinking “I want to write 8-page Google Docs and 6-sentence Slack updates for a living.” But here we are.

Whether you're in DevRel, Product, or Engineering, writing is the glue. It's the thing that makes your ideas move, your team align, and your users understand what you just shipped. And the moment I stopped treating it like a chore and started treating it like a tool, things got better.

So what even counts as “good” writing in our world?

Let’s bring it down to the essentials — no jargon, no fluff:

• Clear: The number one thing. If your reader can’t immediately tell what you're saying or what you want them to do, nothing else matters. Clarity is empathy. It shows you’ve done the work so they don’t have to.

• Concise: We’re all swimming in tabs and context switches. If you can say something in fewer words — do it. Every sentence you cut is a little gift to your reader.

• Useful: Is what you're writing going to help someone? Will it unblock a teammate, teach a user something new, or help someone make a decision? If yes, you're on the right track.

• Contextual: Know your audience. Writing an internal eng spec is very different from writing a changelog for customers. What do they already know? What do they care about? Writing without context is like giving someone directions without asking where they’re coming from.

• Unboring: This one's underrated. No one wants to read something that sounds like a compliance email. We’re still humans reading this stuff. Inject a little personality, a little rhythm. Be real. Even a dry subject can have a clear, kind voice.

If your doc, post, spec, or tweet hits those five — clear, concise, useful, contextual, and unboring — you’re already ahead of 80% of the internet.

And honestly it’s not about being a great “writer.” It’s about being a clear thinker who knows how to get ideas across. That’s the real skill.

My writing hacks (context matters)

DevRel writing - (Tutorials, blogs, guides)

DevRel writing is a strange but beautiful mix of teaching, storytelling, and subtle product marketing. The trick? It should never feel like marketing. It should feel like someone generous and sharp is walking you through something they’ve figured out the hard way.

Here’s what I’ve learned from watching great DevRel folks (and borrowing a few tricks myself):

Start with the “why.” Assume your reader landed on your post while frustrated or curious. Lead with empathy:
“You’re probably running into this error when deploying on XYZ. Here’s a cleaner way to solve it.” or “This new SDK shortcut can save you 40 minutes every deploy.”

Code first, words second. Show them the working snippet early. People trust code more than promises. Once they see it works, they’ll actually read what you wrote around it.

Structure = respect. Use headers, bullets, bold text, copy-paste blocks. Add a TLDR if it’s longer than a screenful. Most readers are skimming at 11 PM with 20 tabs open.

Always test it yourself. If your walkthrough breaks on step 3, your reader’s gone. And so is their trust. I’ve seen brilliant posts having massive drop outs because the author never ran through it fresh.

Sound like a mentor, not a manual. You don’t need to be overly polished. It’s fine — actually it’s helpful — to say: “This part’s a little weird. Took me a few tries to get it right, but here’s what finally worked.”

Product writing - (PRDs, changelogs, release notes)

Product writing isn’t just “PM homework.” It’s the single source of truth for everyone else who has to work with what you're building — engineers, design, support, marketing, sales and even your future self three months from now.

Here’s how I try to approach it:

• Start with the job-to-be-done. Right at the top, one or two lines:
  “This feature lets users schedule deployments without needing to coordinate manually with ops.”
  If that’s not clear, the rest of the doc won’t help. Your team can’t build what they don’t understand.

• Show, don’t just tell. Even a rough Figma mock/Excildraw mock or screenshot beats a block of descriptive text. People process visuals way faster than paragraphs.

• Use concrete workflows. Instead of saying “Improves team collaboration” say:
  “Imagine Alex, a backend engineer, wants to test a feature branch in staging. Now they can trigger an environment preview without waiting on DevOps.”
  Suddenly, it clicks.

• Write for out-loud reading. Whether it’s a spec review or a stakeholder sync someone will read this doc in a meeting. If your writing is stiff or filled with jargon, people will tune out — especially execs.

• Avoid buzzwords like the plague.
  If you find yourself typing “streamlines the end-to-end feedback lifecycle” stop.
  Try: “Makes it easier to leave and respond to feedback in one place.”
  Clear beats clever every single time.

Pro tip:
Write the changelog version before you write the spec.

If you can’t explain what changed and why it matters in two lines, you’re not ready to spec it.

Example:

• Bad changelog line:
  “Introduced a multi-tenant data abstraction layer to enhance platform modularity.”

• Better:
  “You can now manage workspaces across multiple teams from a single dashboard.”

If the second one’s easier to read — it’s because it’s closer to what the user actually experiences.

Engineering writing (RFCs, internal docs)

Your job here is to transfer clarity, not impress people.

• Define terms at the top. Even “what is a satellite” or “what is <service_name>”

• Show tradeoffs early – engs love to know “why this and not X.”

• State the goal like a test case – “This works if…”

• Don’t ignore – Call them out in a “Things to Watch” section.

• Use diagrams. Seriously. A 5-minute sketch saves a 500-word explanation.

Most underrated move? Drop a Loom + Notion summary with your RFC. Eng leads love it.

A few hard-won habits

I’ve learned these the slow way:

• Write your 1-pager before you pitch the project. If you can’t explain the problem, context, tradeoffs, and desired outcome on a page, you're not ready to start.

• Never surprise in writing. Use writing to confirm alignment, not create it. Talk to people first.

• Default to edit over ideate. Most people specifically PMs get stuck because they try to write the perfect doc on the first try. Start ugly. Hit send. Feedback is strategy.

• Name your documents like a dev. I’ve shipped more projects with why-now.md, tradeoffs-v2.md, and launch-readiness.md than any fancy doc template.

• Own the narrative. If you don’t write it, someone else will — and it might not be accurate.

And the most human trick of all? Write as if you’re DMing a smart friend.

Because let’s face it — writing isn’t about sounding smart. It’s about being understood.

Final thoughts

We’re all accidental writers now. And writing is thinking. The clearer you write, the clearer you think. And in product/devrel/eng — clarity wins.

So next time you open Notion, Google Docs, or even Twitter...

Remember: write to help someone get unblock. That’s where the magic is.

That’s the bar. That’s the win.

Thanks for reading! If this resonates, or if you’ve found writing hacks that actually work in fast-moving orgs, I’d love to hear about them.

— Dhrubajyoti
Product @ Harness | Thinking about agent infrastructure, developer experience, and LLM applications.

I’ll admit: my gut reaction was “Wait, doesn’t MCP already kind of cover this?”
And if you’re already building LLM-based applications, you might be asking the same thing.

But as I went deeper into A2A, I started to see how it fills some of the gaps MCP leaves behind — and how these two protocols might actually complement each other in a pretty elegant way.

This post is a breakdown of what’s going on here, why people are excited, and what this means if you’re building agentic apps or thinking about the future of how AI systems will interact.

What’s MCP again?

If you’ve been anywhere near open-source LLM infra over the past few months, you’ve probably heard of MCP (Model Context Protocol).

At its core — MCP is about creating a consistent and modular way for LLM-based apps to interact with tools and data sources. Instead of manually wiring up every API and context window, MCP gives you a structured way to expose capabilities to your model—making it easier to scale and generalize how agents (or apps) access tools.

Here’s the typical breakdown of components in an MCP-powered environment:

MCP Host

At the center of the architecture is the MCP Host. This is your main application —likely powered by a LLM — and it’s responsible for orchestrating everything. It receives requests, makes decisions, and determines which tools or services to invoke. Think of it as the brain that interprets user intent and turns it into meaningful action.

MCP Client

The MCP Client is the bridge between the Host and the broader ecosystem. It standardizes how the Host communicates with tools, services, and external systems. Think of it as the adapter layer—it knows how to speak both the language of the Host and the protocols of the tools it needs to use.

MCP Server

MCP Servers are lightweight service wrappers that expose specific tools or capabilities to the MCP network. Each Server speaks the MCP protocol, making it easy to plug in new capabilities—like running a SQL query, accessing a calendar, or parsing a PDF.

These are stateless, composable, and easy to distribute. You can run as many as you need, where you need them.

Local Data Sources

These are the systems and data stores available on your local machine or network. For example:

• File systems (e.g. reading a .csv)

• Local databases (e.g. SQLite, local Postgres)

• Services that an MCP Server can access behind a firewall

Remote Data Sources

This includes any cloud-based or API-accessible system, such as:

• Google Calendar

• Salesforce

• Notion

• Any custom RESTful service

In short, MCP gives your LLM superpowers by standardizing how it talks to different tools and services. But there's a catch...

Where MCP Falls Short

MCP shines in structured environments where a single LLM agent (or “host”) is accessing tools in a controlled way. But what if you’re building systems where multiple agents need to communicate, negotiate, share state, or divide and conquer tasks?

That’s where things start to get messy.

MCP doesn’t natively handle:

• Agent-to-agent coordination

• Secure handshakes between agents

• Negotiation around user preferences or constraints

• Maintaining or syncing state across multiple independent actors

And that's exactly where A2A steps in.

A2A (Agent-to-Agent)

Google’s new A2A protocol proposes a solution to the decentralized, real-time nature of multi-agent systems.

While MCP focuses on LLM-to-tool interaction, A2A focuses on agent-to-agent collaboration. Think of it as a protocol that lets multiple intelligent agents talk to each other, understand each other’s capabilities, and coordinate securely and effectively.

Here’s how it works:

• Security Layer – A2A adds authentication and identity, which MCP doesn’t natively offer. You can now trust who you're talking to in multi-agent setups.

• Task & State Management – Agents can share, delegate, and sync tasks and state. This is huge for applications where multiple agents are working toward a shared goal or context.

• User Experience – Agents can communicate about user preferences, time constraints, or alternative approaches to solving a problem.

• Capability Discovery – Just like MCP lets a host discover tools, A2A enables agents to discover each other’s abilities, making the system more dynamic.

In other words, A2A makes agents truly agentic — giving them the language and structure to function as autonomous entities in a shared environment.

So… why this protocol debate?

Honestly? It doesn’t have to be.

I’ve seen a lot of folks online sharing thoughts on MCP and A2A against each other as if we’re heading for some kind of VHS vs. Betamax showdown. But the more I think about it, the more I believe they were always meant to converge.

If I had to bet, I’d say the original creators of MCP probably anticipated many of these A2A-style capabilities—task negotiation, agent communication, identity layers— but didn’t prioritize them in the early spec. Why? Because it made sense to first focus on the lower layer: tool interoperability and data access.

Now, A2A picks up where MCP leaves off, addressing the higher-level orchestration layer between agents.

Here’s how I see the two working together:

• Capability & Tool Access → What can I do? → MCP

• Agent Coordination → Who else is out there? How do we work together? → A2A

Together, they could form a powerful stack for future agentic applications:
MCP for accessing tools. A2A for collaborating to get things done.

Final thoughts - What does this mean for you?

If you’re building agent-based systems — whether it’s for internal workflow automation, customer support agents, or research tools—this development is worth paying attention to.

My take?

• If you’re already using MCP, A2A could layer beautifully on top of what you’ve built, adding support for multi-agent coordination without reinventing your whole stack.

• If you’re new to agent systems, you now have two maturing protocols to build with — one focused on execution (MCP), the other on collaboration (A2A).

Either way, we’re watching the early formation of something big here: the standardization of how intelligent agents talk, think, and work together.

And that’s not just hype. That’s essentially the infrastructure for the next generation of software.

Thanks for reading. If you’re building in this space — or just exploring — feel free to connect with me. I’d love to hear how you’re thinking about agent systems, protocol standards, and where it’s all headed.

— Dhrubajyoti
Product @ Harness | Thinking about agent infrastructure, developer experience, and LLM applications.

In this blog, I’ll share some life hacks I use to learn and grow through the feedback I have received so far in my career.

The initial reaction: You get defensive

When it comes to receiving feedback, most of us have an immediate emotional reaction that can be difficult to control. Whether it's a colleague or a senior manager providing their input on our work, our default response may be to feel defensive, dismissed, or even angered by their comments. This is because our brain's automatic response is to protect our ego and self-image.

Imagine you've spent hours writing a new feature for your team's project. However, when you present it to the team, one of your team members points out a few issues with the code. Maybe function names are not descriptive, or maybe the behind-the-scenes logic is not efficient.

The first thought you would probably get is - "But I spent hours on this! It's perfect just the way it is. This person just doesn't understand my vision."

Well, that possibly could be the case but just not most of the time.

Hack 1: The 2-minute rule

Initially, I had the same feeling but then to overcome this what I call the reflex reaction, I tried the 2-Minute Rule. Well now when you receive the feedback, take a 2-minute pause before responding. This is a simple yet very effective hack.

• A brief pause allows your emotions to settle which helps you think rationally. Research shows that even short breaks can significantly reduce stress responses.

• Taking a step back helps you view the feedback without personal bias, focusing on its content rather than delivery.

• It essentially allows you to fully consume the information and assess its value to your growth.

What you essentially do here is create a buffer between your initial reaction and your response. This will allow you to listen carefully which is probably one of the most important skills when it comes to receiving feedback and also can help in responding in a more constructive and open-minded way.

Hack 2: Frame feedback as a question

Let's go back to the previous example. You've just received feedback on your code, and you're feeling defensive. Now to channel your initial reaction, try reframing the feedback as a question. For example:

• Instead of "Your code is not efficient" reframe it as "What can I do to improve the efficiency of my code?" “What is the impact it causes?”

• Instead of "Your function names are not descriptive," reframe it as "What are the other possible function names that are more descriptive and clear?"

Ask yourself the reframed question, try to come up with a solution and then use the solution as a starting point for your response. This shift in perspective creates the foundation of a growth mindset, encouraging problem-solving over blame.

Try to understand the usefulness of the feedback

Once you've added your initial reaction, it's essential to understand the usefulness of the feedback. Not all feedback is equally helpful. Remember, you're the expert on your work. While others offer valuable perspectives, the ultimate goal is improvement. At the end of the day, you are the one who worked on the code and who essentially understands it the best. The best feedback can be yours.

Let's say you've received feedback on your code from a colleague. They've pointed out a few issues with the logic, and they've suggested some alternative approaches. However, as you review the feedback, you realize that the colleague's suggestions are not relevant to the specific problem you're trying to solve.

In this case, you need to assess the usefulness of the feedback and decide whether to act on it or not.

Hack 3: The 3-Part feedback filter

I use this almost every day. To assess the usefulness of feedback, try using the 3-Part feedback filter. This hack can help you:

• Understand the feedback objectively

• Identify what is valuable and what is not

• Prioritize your work items based on the feedback\

To use the 3-Part feedback filter get answers to the following questions:

1. Is the feedback specific, clear, and actionable? Does it provide concrete examples or suggestions?

2. Is the feedback relevant to the specific problem or goal you're trying to achieve? Does it align with your priorities and in some cases values?

3. Do you have a clear action item based on the feedback? Is it feasible to implement the suggested changes or improvements?

You can use this method to consistently evaluate feedback from colleagues, managers, and mentors. Now for this method to work you will have to be honest with yourself considering some feedback may not be worth acting on.

How I see this is essentially like where feedback is not always right or wrong. It's often a matter of perspective, and you need to use your judgment to decide what to do with it.

Use feedback as a source of constant growth

Let’s consider the previous example where you have received feedback from your colleagues and manager on your code, and you've used it to make significant improvements. As a result, you've become more confident in your abilities and more efficient in your work.

However you realize that you're not getting as much feedback as you used to. Your colleagues and manager are not pointing out as many issues, and you're not sure if you're still improving.

In this case, you can use the Feedback Loop method to drive your growth using continuous feedback.

Hack 4: The feedback loop

Imagine you're driving a car, and you're trying to reach your destination. You're not just looking at the road ahead, but also checking your rearview mirror, side mirrors, and GPS to ensure you're on track. This process of checking, adjusting, and re-checking is similar to a feedback loop.

A Feedback Loop is a cycle of:

• Action: You take an action, like driving the car or writing a piece of code.

• Feedback: You receive feedback, like a GPS alert or a colleague's comment, that tells you how you're doing.

• Adjustment: You use the feedback to adjust your action, like turning the steering wheel or refactoring your code.

• Repeat: You repeat the cycle, taking a new action, receiving feedback, and adjusting again.

Now in software engineering let’s understand this using an example where you're working on a new feature and you've written a piece of code, but you're not sure if it's the best solution. You want to make sure it's efficient, scalable, and meets the requirements.

Now in this scenario, the Feedback Loop becomes a cycle of:

1. Writing Code: You write a piece of code, like a function or a module.

2. Get Feedback: You receive feedback from your peers, like a code review or a test report, that tells you how your code is performing.

3. Refactor: You use the feedback to refactor your code, making improvements and optimizations.

4. Repeat: You repeat the cycle, writing new code, getting feedback, and refactoring again.

Examples of Feedback Loops in Action

• A dev team using CI/CD pipelines to automate testing.

• A developer using a code review tool such as the Github Copilot to receive feedback from peers and improve the code quality.

• A Devops team using monitoring and logging tools to receive feedback on system performance and make adjustments.

To use the method you essentially have to trim down your focus area i.e. you’ll have to identify a specific space where you would want to improve.

Closing thoughts

Receiving feedback can be challenging, but it's essential for the growth of software engineering. Try using the hacks mentioned in this blog and share your experience.

Most importantly remember that affirmations can always help us stay on track, focusing on the type of software engineer we want to be, the thoughts and behaviour we aim to display, and the kind of person we want to be.

So, the next time you receive feedback, take a deep breath, repeat the affirmation, and use it as a growth opportunity. Your future self will thank you!

Let me explain it in simpler terms. Langchain provides a platform for developers to connect data to language models, such as GPT models from OpenAI and various others, through their API. It provides a collection of modular components and utilities that simplify the process of building applications that leverage the capabilities of LLMs.

Why do we need LangChain?

Developers often lack the necessary tools to deploy language models in real-world use cases as the ecosystem for building GenAI applications is still evolving. Starting scratch to work with LLMs directly can be a bit complex with tasks such as prompt engineering, data preprocessing, managing context and memory, and handling different model APIs and output formats. LangChain abstracts away much of this complexity, providing a higher-level interface for interacting with LLMs.

Many real-world applications require combining multiple operations or tasks involving LLMs, such as retrieving information from databases, processing text data, and generating outputs based on specific prompts. LangChain's concept of "chains" and "agents" makes it easier to create and manage these complex workflows.

The best part is that you can do all of this within a single interface. No more crazy scaling of code bases just to support different providers!

The community behind

When it comes to the future of any technology framework, one of the big factors is the community supporting it. And for projects like Langchain, this is even more crucial. You want to know you're not flying solo, right?

Langchain has got a massive fan base! As of today, it's got over 51k stars on GitHub, which is a pretty credible stat for its popularity in the open-source space.
It's racking up a million downloads every single month with some serious love from the developer community.

The community also maintains an active Discord channel. So, if you ever hit a blocker or just want to experiment around you know that you've got a place to hang out.

LangChain Community: Click Here

LangChain Documentation: Click Here

Bottom line: with that kind of following and engagement, you can bet Langchain is doing something right. Let's now try to understand what exactly all of this hype is about.

What does LangChain really do?

Complexity Abstraction

At its core, LangChain acts as an abstraction layer, allowing developers to interact with various LLMs through a consistent and user-friendly interface. This abstraction simplifies the process of working with different LLM providers, APIs, and models, enabling seamless model interoperability and facilitating the integration of multiple LLMs within a single application.

Chaining

Beyond abstraction, LangChain introduces the concept of "chains," which are sequences of operations that can be applied to inputs or outputs of LLMs. These chains can be combined and orchestrated to create more complex workflows, enabling developers to build sophisticated applications that leverage the strengths of LLMs in various capacities. For example, a chain could involve retrieving data from a database, processing and summarizing that data using an LLM, and then generating a natural language response based on the processed information.

For example, you can define a custom chain that retrieves relevant information from various data sources, processes it using an LLM, and generates a natural language response:

from langchain import OpenAI, GooglePalm, Anthropic
from langchain.chains import RetrievalQA

# load models

openai_llm = OpenAI(model_name="text-davinci-003")
palm_llm = GooglePalm(model_name="palm-2")
claude_llm = Anthropic(model_name="claude-v1")

# chain definition

chain = RetrievalQA(
    retriever=...,  # retriever for fetching relevant information
    question_llm=openai_llm,  
    answer_llm=palm_llm,  
    feedback_llm=claude_llm,
    ...
)

# use the chain to answer questions

result = chain.run("What is the capital of India?")

The above code is an example on how you can integrate and use multiple LLMs within the same application, without having to worry about the underlying complexities of interacting with each provider's API directly. The RetrievalQA chain abstraction handles the orchestration of different LLMs for different subtasks (generating questions, answers, and feedback).

Memory and Context Management

LangChain can manage memory and context effectively. Most LLMs often struggle to maintain coherent and consistent responses across multiple interactions due to their limited context retention capabilities. LangChain addresses this limitation by providing tools for managing and persisting context, allowing applications to maintain relevant information and provide more coherent and contextually-aware responses.

from langchain import OpenAI, ConversationBufferMemory

# initialize the LLM and memory

llm = OpenAI(temperature=0)
memory = ConversationBufferMemory()

# set up the conversation chain

from langchain.chains import ConversationChain
conversation = ConversationChain(llm=llm, memory=memory)

# start the conversation

print(conversation.predict(input="Hi there!"))
# -> 'Hi there! It's nice to meet you. How can I assist you today?'

print(conversation.predict(input="I'm looking for information about the French Revolution."))
# -> 'Sure, I'd be happy to help you with that. The French Revolution was a major event in European history...'

print(conversation.predict(input="What were some of the key causes?"))
# -> 'Some of the key causes of the French Revolution included...'

print(conversation.predict(input="And what were the major outcomes?"))
# -> 'The major outcomes of the French Revolution were...'

In this example, we first initialize an OpenAI LLM and a ConversationBufferMemory object, which will be used to store and manage the conversation context.

Next, we create a ConversationChain and pass it to the LLM and memory objects. This chain is designed to maintain and utilize the conversation history to provide more coherent and contextually-aware responses.

As we interact with the ConversationChain through the predict method, the chain stores the input prompts and generated responses in the ConversationBufferMemory. When a new input is provided, the chain retrieves the relevant context from the memory and prepends it to the prompt before sending it to the LLM.

You'll notice that in the example, even though the prompts "What were some of the key causes?" and "And what were the major outcomes?" don't explicitly mention the French Revolution, the LLM can still provide relevant responses based on the context maintained in the ConversationBufferMemory.

LangChain provides several different memory implementations, including ConversationBufferMemory, ConversationBufferWindowMemory (which limits the context to a specific number of interactions), and ConversationEntityMemory (which can extract and store specific entities from the conversation). You can also implement custom memory classes to suit your specific use case.

Model Agnostic

Different LLMs have different APIs, input/output formats, and capabilities. LangChain provides a unified interface for working with various LLMs, allowing developers to switch between models or use multiple models in the same application without significant code changes.

Data Ingestion & Monitoring

LangChain simplifies the process of ingesting and working with diverse data sources, such as text files, PDFs, websites, and databases. It provides utilities for preprocessing and formatting data, ensuring that it is compatible with the input requirements of LLMs. This data integration capability enables developers to leverage the power of LLMs with real-world data sources, unlocking new possibilities for processing and generating insights from complex and unstructured data.

It also offers utilities for evaluating and monitoring the performance of LLM-based applications, including tools for generating and analyzing metrics. This feature allows developers to assess the effectiveness of their applications, identify areas for improvement, and optimize their use of LLMs.

from langchain.document_loaders import TextLoader, PyPDFLoader, WebBaseLoader
from langchain.text_splitter import CharacterTextSplitter
from langchain.vectorstores import Chroma
from langchain.chains import RetrievalQA
from langchain.llms import OpenAI
from langchain.evaluation import LoadAndEvaluateQA

# ingest the data
loaders = [
    TextLoader('data/text_files/'),
    PyPDFLoader('data/pdfs/'),
    WebBaseLoader('https://example.com')
]

documents = []
for loader in loaders:
    docs = loader.load()
    text_splitter = CharacterTextSplitter(chunk_size=1000, chunk_overlap=0)
    texts = text_splitter.split_documents(docs)
    documents.extend(texts)

# create a vector store
vectorstore = Chroma.from_documents(documents, persist_directory='vectorstore')

# create a retrieval chain
llm = OpenAI(temperature=0)
qa = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=vectorstore.as_retriever()
)

# evaluate and monitor
dataset = LoadAndEvaluateQA.load_from_file('data/qa_dataset.json')
metrics = LoadAndEvaluateQA.evaluate(qa, dataset)
print(metrics)

In the above code example, we start by ingesting data from various sources: text files, PDFs, and a website. We use LangChain's TextLoader, PyPDFLoader, and WebBaseLoader to load these documents. We then split the documents into smaller chunks using the CharacterTextSplitter to ensure that they are compatible with the input requirements of the LLM.

Next, we create a vector store using Chroma, which is a tool for ingesting and storing documents in a format suitable for retrieval and querying.

With the vector store in place, we create a RetrievalQA chain, which combines a retriever (in this case, the vector store) with an LLM (OpenAI's GPT-3) to answer questions based on the ingested data.

Finally, we use LangChain's evaluation and monitoring tools to assess the performance of our question-answering application. We load a dataset of question-answer pairs (LoadAndEvaluateQA.load_from_file('data/qa_dataset.json')) and evaluate the RetrievalQA chain against this dataset using the LoadAndEvaluateQA.evaluate function. This function returns a dictionary of metrics, such as accuracy, precision, recall, and F1 score, which we can use to monitor and optimize the performance of our application.

Closing thoughts

LangChain has proven to be a valuable tool for working with large language models (LLMs) by simplifying the complexities involved. But to make a solid point - the APIs for these language model things are constantly evolving. Who knows, maybe down the line they'll just bake in a bunch of the functionality that LangChain provides right now. That could make LangChain a little redundant, or at least force it to switch things up a bit.

What I do think is that LangChain's model-agnostic approach could position it as a standard interface for LLMs across different platforms If it becomes like the go-to interface for working with any language model out there, that'd be a pretty sweet spot to be in.

Whichever way it shakes out, you have to appreciate the LangChain team for putting in the work to build something that's legitimately useful right now. They've helped a lot of folks to essentially build use case driven apps using LLMs. Even if LangChain ends up evolving or getting replaced down the line, their contribution to pushing this space forward is solid.

About me

I am currently a Product Manager at Harness.io working on Software Engineering Insights — building software that help teams understand and improve how software gets built.

Before that, I spent time in Developer Relations, where I focused on translating feedback into product and helping developers succeed with the platform.

Most of my work revolves around making ML systems more usable in production. I have explored a range of ideas from training large models to building scalable MLOps architectures. I try to explain complex things simply.

Background in physics. Learned AI the long way.
Built some things, broke others. Still learning.

You can find some of my experiments on HuggingFace
Always open to interesting conversations — reach out at me@codewdhruv.com or connect on LinkedIn.

Subscribe now