DEV Community: Nimesh Kulkarni

Beyond Chatbots: How Hermes Agent Turns an LLM Into an AI Worker

Nimesh Kulkarni — Thu, 20 Aug 2026 19:26:39 +0000

Hermes Agent: What Happens When an LLM Gets Memory, Tools, and a Work Loop?

Most LLMs are pretty good at talking.

Give them a prompt, they generate an answer. Done.

But the moment you ask an AI to actually do something, things get more interesting.

Search the web.
Run a command.
Read a file.
Remember what happened yesterday.
Create a skill.
Try something, check the result, and keep going.

Now you are no longer just dealing with an LLM.

You are building an agent system.

And this is where Hermes Agent gets interesting.

So, What Is Hermes Agent?

Hermes Agent is an open source AI agent built around an LLM.

The interesting part is not simply the model underneath it. The interesting part is everything built around that model:

Tools + Memory + Skills + Agent Loop + Sub-agents

The LLM is basically the brain.

The harness around it gives that brain a way to actually do things.

The Agent Loop

When you give Hermes a task, it does not necessarily answer immediately.

It can follow a loop:

Understand the task
Decide what needs to happen
Choose a tool
Execute the tool
Look at the result
Decide what to do next
Repeat if necessary
Return the final result

That last part is important.

The agent can continue working instead of expecting the user to manually guide every single step.

That's the difference between:

"Tell me how to deploy this."

and:

"Deploy this."

The second one requires an actual agent.

SOUL.md: Give the Agent a Personality

One of the interesting pieces is SOUL.md.

Think of it as the instruction layer that defines how the agent should behave.

It can describe things like:

Personality
Communication style
Priorities
General behavior
Rules the agent should follow

The underlying model can stay the same, but the system around it can make the agent behave very differently.

The model provides the intelligence.

The instructions shape how that intelligence is used.

Then Comes Memory

This is where things get really interesting.

A useful agent cannot depend entirely on the current conversation.

It needs to remember.

Hermes uses different memory layers for different purposes.

Procedural Memory: Skills

Procedural memory is basically:

"How do I do this?"

If the agent learns a useful process, it can save that process as a reusable skill.

For example:

Imagine the agent learns your preferred workflow for deploying an application.

Instead of figuring it out from scratch every time, that procedure can become a skill.

The next time the task appears, the agent already has a starting point.

That's a huge difference.

The agent isn't just remembering information.

It is remembering how to work.

Semantic Memory: Facts

Semantic memory is:

"What do I know?"

This is where useful long term information can live.

User preferences.

Project information.

Important facts.

Frequently used tools.

For example:

"The user prefers reports in a short technical format."

You don't need to keep the entire conversation to remember that.

You just need the useful fact.

Episodic Memory: History

Then there is episodic memory.

This is:

"What happened?"

It contains previous interactions, conversations, activities, and agent history.

Think of it like the agent's experience log.

But there is a problem.

This can get huge.

You don't want to throw the entire history of an agent into the context window every time it needs to answer a question.

So the interesting part is how useful information can move from large historical data into smaller, more useful memories.

That's where summarization becomes important.

Memory Is Not Just a Database

This is an important distinction.

When people say:

"Let's add memory to the agent."

they sometimes mean:

"Let's connect a vector database."

That's only part of the problem.

A real memory system needs to answer:

What should be remembered?

Where should it be stored?

When should it be retrieved?

When should old information be summarized?

What information is actually useful?

The hard part isn't storage.

The hard part is memory management.

Tools: Now the Agent Can Actually Do Stuff

Memory lets the agent remember.

Tools let it act.

Hermes can work with tools such as:

Terminal

Run commands, interact with files, and work with the local environment.

Browser

Search websites, collect information, and use the web as part of a task.

Scheduled Tasks

The agent can schedule work to happen later instead of waiting for another user message.

Skills

Save useful workflows and reuse them later.

Sub-agents

For larger tasks, work can be delegated to another specialized agent or coding tool.

This creates an interesting architecture.

Hermes does not have to do every piece of work itself.

It can manage the bigger task and delegate specific jobs when needed.

Local Memory Is a Big Deal

Another interesting part of Hermes is local storage.

The agent's memory can live on your own computer.

That means the information it remembers does not necessarily have to live entirely inside some remote cloud memory service.

For an agent that can accumulate:

Conversations
User preferences
Project information
Skills
Task history

local storage gives the user much more control over that information.

But There Is Still a Missing Piece

Now we get to something that is often ignored when people talk about AI agents.

How do you know the agent is actually getting better?

An agent can have memory.

It can have tools.

It can have skills.

It can run complicated workflows.

But none of that automatically tells you whether it is performing well.

This is where LLM Ops comes in.

And importantly, LLM Ops is not the same thing as Hermes itself.

LLM Ops: The Layer Watching the Agent

Think of LLM Ops as the engineering layer around the agent that helps you understand what happened during a run.

A trace can capture the agent's trajectory.

Then evaluation can ask:

Was the result actually good?

At the same time, observability can track things like:

Token usage
Latency
Errors
Tool calls
Execution behavior

If something fails, you need to know why.

Was the prompt bad?

Did the model choose the wrong tool?

Did a tool return a bad result?

Did retrieval fail?

Did the agent simply make a bad decision?

That is where diagnosis becomes useful.

Then comes the gate.

If the evaluation passes, the change can be released.

If it fails, you fix it, run the evaluation again, and repeat.

That creates a proper engineering loop:

Trace → Evaluate → Observe → Diagnose → Gate → Release

Now you're not just building an agent.

You're building a system you can actually improve.

The Bigger Picture

This is what makes agent engineering different from simply calling an LLM API.

An LLM gives you intelligence.

But an agent needs infrastructure around that intelligence.

Memory gives it continuity.

Skills give it reusable procedures.

Tools give it the ability to act.

The agent loop lets it work through multiple steps.

Sub-agents let it delegate complex work.

LLM Ops lets you understand and improve what happened.

Put all of these together and you get something much closer to an actual AI worker.

The Real Shift

The interesting shift in AI isn't:

"LLMs can generate text."

We already know that.

The bigger shift is:

LLMs can be placed inside systems that remember, act, evaluate, and improve.

That's what makes agent infrastructure so interesting.

The model is only one component.

The real engineering challenge is building everything around it.

And Hermes is a great example of what that architecture can look like.

Final Thought

A chatbot waits for your next prompt.

An agent can work toward a goal.

That's a pretty big difference.

And once you add memory, skills, tools, delegation, and proper LLM Ops around the model, the question stops being:

"What can this LLM answer?"

and becomes:

"What can this system actually get done?"

If you like reading drop a like 🤍

About me
👀

Agentic Memory System Design

Nimesh Kulkarni — Wed, 19 Aug 2026 19:38:18 +0000

AI Agent Memory System: How Agents Remember

An AI agent can answer questions using the information available in the current conversation. But if we want the agent to remember users, past conversations, important facts, or previous work, we need a proper memory system.

Why Does an Agent Need Memory?

Without memory, an agent mostly depends on its current conversation. Once that context is gone, it cannot easily use what happened before.

Memory allows an agent to remember useful information and bring it back when it is needed.

Three Types of Agent Memory

1. Procedural Memory

Procedural memory tells the agent how to do something.

It contains instructions, skills, workflows, or rules that guide the agent. For example, an agent can have a skill file that explains how it should perform a particular task.

2. Semantic Memory

Semantic memory stores important facts.

For example, if a user says, “There is a hackathon next week,” the system can store a simple fact like “Hackathon next week.”

This keeps the useful information without storing the entire conversation. Semantic memory can be stored and retrieved using a vector database.

3. Episodic Memory

Episodic memory stores what happened before.

It can contain previous conversations, agent responses, activities, and other past interactions. Think of it as the agent’s history.

The Problem With Too Much Memory

Episodic memory can become very large as the agent keeps interacting with users. Giving the complete history to the LLM every time is not efficient.

That is why useful information from episodic memory can be summarized and converted into smaller facts for semantic memory.

The Summarizer Agent

Instead of summarizing memory after every interaction, we can introduce a gate or threshold.

For example, after 20 activities or conversations, the system can trigger a summarizer agent. The summarizer looks at the recent episodic memory, identifies the important information, and saves it as useful facts in semantic memory.

This gives us better control over what to store, how to store it, and when to store it.

Final Thought

Good agent memory is not about remembering everything. It is about remembering the right information at the right time.

Procedural memory tells the agent how to work, semantic memory tells it what it knows, and episodic memory tells it what happened.

Together, these make an AI agent much more useful and capable over time.

if you like reading drop a like :D

AI Is Not Just Replacing Work, It Is Challenging How We Think

Nimesh Kulkarni — Sat, 27 Jun 2026 13:25:58 +0000

For a long time, we treated AI like a tool.

Something that could autocomplete code, summarize long documents, generate images, or answer simple questions. It felt useful, but still limited. The human was always the thinker, and AI was just the assistant.

That line is slowly becoming blurry.

Today, AI can reason through problems, debug code, write product strategies, explain complex systems, generate architecture diagrams, and even challenge our assumptions. It does not just give answers anymore. It can break down problems in a way that looks very close to thinking.

For developers, this is both exciting and uncomfortable.

We used to believe that writing syntax was the main skill. Then AI made syntax cheap. Now we say problem solving matters more. But AI is also getting better at problem solving. It can compare approaches, suggest tradeoffs, identify bugs, and explain why one solution is better than another.

So the real question is not whether AI will overtake human thinking completely.

The better question is: what kind of thinking will still matter?

Blind execution will lose value. Copying tutorials will lose value. Writing basic CRUD apps will lose value. But taste, judgment, creativity, clarity, and understanding real human problems will become more important.

AI can generate ten solutions in seconds, but someone still has to decide which one is actually useful. AI can write code fast, but someone still has to understand the product, the users, the constraints, and the long term impact.

The future developer will not be the person who simply writes code.

The future developer will be the person who knows what to build, why it matters, how to guide AI properly, and how to judge the output with real understanding.

AI may overtake many thinking tasks, but it will also expose who was truly thinking in the first place.

The people who only memorized steps will struggle.

The people who understand systems, ask better questions, and keep learning will become more powerful than ever.

How AI Is Quietly Automating 70% of Customer Support

Nimesh Kulkarni — Wed, 10 Jun 2026 13:57:05 +0000

Customer support automation used to mean rigid chatbots, scripted menus, and irrelevant help centre links.

That is changing fast.

Platforms like Zendesk, Intercom, and Freshworks now use large language models to understand customer questions, search company knowledge, complete basic actions, and escalate complex issues to human agents.

In some deployments, these platforms report automation or resolution rates near 70%.

That does not mean 70% of support jobs have disappeared. It means a large share of repetitive customer conversations can now be resolved without an agent manually handling every step.

What AI Support Agents Can Do

Modern AI agents can:

Understand natural language
Identify customer intent
Search approved documentation
Generate contextual answers
Check order or account information
Process simple requests
Summarize conversations
Transfer difficult cases to humans

Unlike traditional chatbots, they do not depend entirely on fixed decision trees.

A customer can write:

«I paid for the upgrade, but my account is still on the free plan.»

The AI can understand that this is not just a general billing question. It may need to verify the payment, check the subscription status, and escalate the case if the account was not updated correctly.

Why Support Is Easy to Automate

A large percentage of support volume comes from repetitive questions:

How do I reset my password?
Where is my order?
How do I download an invoice?
Can I cancel my plan?
How do I add a team member?

These questions are important, but they usually follow predictable patterns.

AI is good at understanding the request, retrieving the correct information, and presenting it clearly. When connected to business systems, it can also complete the task instead of simply explaining it.

The Human Role Is Changing

AI will not remove the need for human support.

It will change what human agents handle.

AI can manage simple and repetitive requests. Humans can focus on:

Complex technical issues
Sensitive complaints
Security incidents
High-value customers
Unusual exceptions
Retention conversations

AI can also assist human agents by drafting replies, summarizing long conversations, translating messages, and retrieving relevant documentation.

The 70% Figure Needs Context

Not every company will automate 70% of its support volume.

The result depends on:

The quality of the knowledge base
The types of customer questions
Access to business systems
Escalation rules
Workflow design
How resolution is measured

A company with clear documentation and thousands of repetitive questions may achieve a high automation rate.

A company handling legal, medical, financial, or highly technical cases may require more human involvement.

The Biggest Challenge Is Knowledge

AI support agents are only as reliable as the information available to them.

Outdated articles, conflicting policies, and missing documentation can lead to incorrect answers.

This is why AI support projects often become knowledge management projects.

Companies must clean their documentation, remove duplicate information, define clear policies, and continuously review failed conversations.

Final Thoughts

AI is not quietly replacing customer support.

It is quietly automating the predictable parts of it.

Platforms like Zendesk, Intercom, and Freshworks are turning support bots into agents that can understand questions, retrieve information, complete actions, and escalate when necessary.

The goal should not be maximum automation.

The goal should be reliable resolution.

AI should handle repetitive work quickly, while humans remain responsible for the situations that require judgment, empathy, and accountability.

I kept skipping events alone. So I built Evento to fix that.

Nimesh Kulkarni — Sun, 07 Jun 2026 17:32:12 +0000

For a long time I had a habit of finding events I was genuinely excited about and then not going.
Not because I did not want to. Because my friends were busy. Or not interested. Or I just could not bring myself to walk into a room full of strangers alone.
Concerts. Hackathons. Local treks. Community meetups. I would find them, get excited, and then talk myself out of going because I had no one to go with.
At some point I asked myself a simple question. What if I could find someone else who is already going to that same event?
That is Evento.
It matches you with verified people going to the same events as you. Real profiles, verified users, no randomness. Whether you are introverted, shy, or just have a friend group that is always somehow busy on the exact weekend you want to do something, Evento is built for exactly that feeling.
I am not building this for some abstract user persona. I built it because I was tired of skipping things I actually wanted to do.
Launching in few days. If this sounds like something you have needed, the waitlist is open right now.
https://evento.n1m35h.in/waitlist

AI Companies Are Paying Millions for Your Old Reddit Posts. Here's Why That Should Concern You.

Nimesh Kulkarni — Sat, 06 Jun 2026 10:06:04 +0000

I am so tired of opening my code editor and seeing the same AI-generated dashboard. Same layout. Same gradient. Same components. It all looks like it came out of the same broken photocopier.

Here is what is actually going on.

Models trained on AI output degrade over time. Researchers call it model collapse. Every generation trained on synthetic data gets slightly worse than the last. Diversity drops. The weird, specific, human stuff disappears. Everything drifts toward a boring average.

By April 2025, over 74% of newly created webpages had AI-generated text in them. Stack Overflow drowned in AI answers overnight. Content farms switched to pure synthetic output the moment it became cheap enough.

The web is now mostly a mirror reflecting a mirror.

So what are OpenAI, Google, and Anthropic doing about it? They are going back to the old internet. Pre-2022. Before the flood. Google signed a $60 million per year deal with Reddit just to access your old posts. OpenAI did the same. Anthropic got sued for taking it without asking.

Your decade-old forum arguments and niche shitposts are now formally worth more than anything being written today. That is not an exaggeration. That is a business decision backed by hundreds of millions of dollars.

Every boilerplate component you copy from an AI, every SEO article generated in bulk, every "here is a step by step guide" that reads like nothing, is feeding a loop that makes the whole thing worse.

I do not have a clean solution to pitch at the end of this. I am just a developer who is bored and annoyed that genuine human output has become the scarce resource in a world drowning in content.

Write something real. Even if it is ugly.

Vite Just Got a Bigger Engine: Why VoidZero Joining Cloudflare Matters

Nimesh Kulkarni — Fri, 05 Jun 2026 12:33:31 +0000

If you build frontend apps in 2026, there is a good chance Vite is somewhere in your workflow. Maybe directly. Maybe through your framework. Maybe through a test runner, plugin, or starter kit you barely think about anymore.

That is why VoidZero joining Cloudflare is worth paying attention to.

VoidZero is the team behind Vite, Vitest, Rolldown, Oxc, and Vite+. Cloudflare says those projects will stay open source, vendor-agnostic, and community-driven. The interesting part is not “company acquires tooling team.” The interesting part is what this signals for the next phase of JavaScript tooling: faster, more integrated, and closer to production runtimes.

The JS toolchain is finally consolidating

For years, frontend tooling felt like a group project where everyone submitted a different build system at 11:59 PM.

Bundler here. Transpiler there. Test runner somewhere else. Dev server doing its own thing. Then your production runtime casually has different behavior because, of course, why not.

Vite changed the default expectation: local dev should feel instant, framework authors should get a solid foundation, and teams should not need a PhD in build configs just to ship a button.

VoidZero pushes that further with projects like:

Vitest for fast testing that feels native to Vite projects
Rolldown as a Rust-powered bundler direction for the ecosystem
Oxc for fast parsing, transforming, linting, and formatting foundations
Vite+ as a commercial layer around the open tooling

The vibe is clear: less glue code, fewer duplicated pipelines, faster feedback loops.

Why Cloudflare is an interesting home

Cloudflare has been leaning hard into developer infrastructure: Workers, Pages, D1, KV, R2, Durable Objects, Workflows, AI tooling, and local development around workerd.

The key developer pain here is simple: local dev should match production more closely.

Cloudflare’s Vite plugin already runs server code inside workerd, the same open-source runtime model behind Workers. That means you can test platform features locally without pretending everything is just Node.js.

That is a big deal. Ngl, “works locally, breaks in production” is one of the least funny recurring jokes in web dev.

What developers should actually do now

Do not rewrite your stack because of one announcement. That is how we summon yak-shaving demons.

Instead, make a small practical check:

npm create vite@latest
npm install -D vitest

If you are already on Vite, review whether your project still has old build/test glue that Vite-native tooling can replace. If you deploy to edge or serverless runtimes, check whether your framework has a runtime-aware Vite integration instead of relying on generic Node-only assumptions.

Also, keep an eye on Rolldown and Oxc. Not because you need to migrate today, but because the performance work happening there will likely show up through frameworks and tools before most app teams touch it directly.

The takeaway

VoidZero joining Cloudflare is not just frontend ecosystem gossip. It is another sign that the JavaScript toolchain is moving from “many separate tools wired together” toward “one faster pipeline from dev to deploy.”

For developers, the win is simple: fewer weird config layers, faster feedback, and local environments that behave more like production.

That is the kind of boring infrastructure improvement that quietly makes everyone ship better software. Lowkey, those are the best ones.

Kubernetes Dashboard Is Passing the Baton — Headlamp Is the Upgrade Path

Nimesh Kulkarni — Thu, 04 Jun 2026 12:34:18 +0000

Kubernetes Dashboard has been that classic “first window into the cluster” for a lot of devs. You install it, click around pods and services, and suddenly Kubernetes feels less like dark magic.

But the Kubernetes project is now clearly pointing users toward Headlamp as the modern replacement path. And honestly? That makes sense.

This is not just a UI swap. It is a small signal about where Kubernetes tooling is going: less “one built-in dashboard for everyone” and more extensible, safer, workflow-friendly interfaces around real cluster operations.

Why this shift matters

The old Dashboard solved a real onboarding problem: “What is running in my cluster?”

But production Kubernetes teams need more than that:

clearer visibility across namespaces and workloads
safer access patterns for different users
plugin-friendly workflows
better alignment with modern cluster operations
a UI that can grow without becoming a giant one-size-fits-all panel

That is where Headlamp is interesting. It is a CNCF project built as a Kubernetes UI that can be extended, embedded into workflows, and used across different cluster setups.

Lowkey, this is exactly what Kubernetes tooling needed. Not another shiny control panel. A better foundation.

The practical developer takeaway

If you are still using Kubernetes Dashboard for learning or lightweight inspection, you do not need to panic-migrate today.

But if you are building team workflows, internal platforms, or anything close to production, start treating Headlamp as the thing to evaluate next.

A simple migration mindset:

Learning cluster / quick inspection
  -> Dashboard is okay for now

Team platform / shared cluster UI
  -> Evaluate Headlamp

Production ops workflow
  -> Combine UI access with RBAC, audit logs, and CLI/GitOps flows

The important part is not “UI vs CLI.” Real teams use both. The UI helps people understand and inspect. The CLI and GitOps pipelines keep changes controlled and repeatable.

Do not skip the boring security bits

Any Kubernetes UI is only as safe as the permissions behind it.

Before rolling one out, check:

Does every user have the minimum RBAC they need?
Are admin actions limited to the right people?
Is access behind SSO or your normal identity layer?
Can you audit who viewed or changed what?
Are destructive actions restricted?

Because a beautiful cluster UI with overpowered permissions is just a very polished footgun. Fr.

My take

The Dashboard-to-Headlamp transition is a healthy move. Kubernetes is mature enough now that the default UX should not just be “show me objects.” It should support real operational workflows.

For developers, the move is simple: keep using visual tools to learn faster, but design production access like an engineering system, not a convenience shortcut.

Actionable takeaway: if your team exposes a Kubernetes UI, review the RBAC model this week and test Headlamp in a non-prod cluster before the migration becomes urgent.

Agent-Native Desktops Are Coming: Code Review Is the First Workflow to Fix

Nimesh Kulkarni — Wed, 03 Jun 2026 12:32:46 +0000

AI coding tools are moving from “chat box next to your editor” to something much more serious: agent-native developer environments.

GitHub just pushed this direction hard with the Copilot app and desktop-style agent workflow announcements. OpenAI is also framing Codex as a broader productivity layer, not just a coding prompt. The signal is pretty clear: agents are becoming part of the work surface, not a side quest.

That sounds futuristic, but for most teams the first real place to care is boring and practical: code review.

The problem is not generation anymore

Generating code is no longer the impressive part. Most teams already know an AI assistant can draft a component, write tests, explain a stack trace, or refactor a file.

The messy part is everything after generation:

Which agent changed what?
Did it understand the existing architecture?
Are the tests meaningful or just green-looking?
Is the diff safe enough to merge?
Who owns the final decision?

Ngl, this is where “AI boosted my productivity” can quietly become “AI created a review queue I do not trust.”

Agent-native means workflow-native

An agent-native desktop should not just be a nicer chat UI. The useful version gives agents a real workflow:

Task context: issue, branch, constraints, and acceptance criteria
Workspace access: repo, terminal, tests, docs, and dependency graph
Change tracking: clean diffs, summaries, and decisions made
Review gates: lint, tests, security checks, human approval
Memory boundaries: what the agent can reuse, forget, or escalate

That is the difference between “vibe coding with a powerful autocomplete” and “delegating a small engineering task with guardrails.”

Start with the review loop

If your team wants to adopt agentic coding without chaos, do not begin by letting agents ship bigger features. Begin by making reviews easier to trust.

A practical setup can be simple:

agent_review:
required:
- summarize_diff
- list_risk_areas
- run_tests
- flag_security_sensitive_files
- explain_remaining_uncertainty
human_decision: required

The magic is not the YAML. The magic is forcing the agent to show its work before a human approves the merge.

What developers should watch next

The next wave of dev tools will compete on orchestration, not just model quality. The best tools will help us manage multiple small agents, compare their changes, rerun checks, and keep review context visible.

That is a big deal because developers do not need more random AI output. We need tighter loops, cleaner diffs, and less context switching.

Takeaway

Agent-native desktops are worth watching, but do not wait for the perfect tool. Start designing your workflow like agents are junior teammates: give them scoped tasks, require evidence, and keep humans in charge of merge decisions.

That is how AI coding becomes useful in real teams: not louder, just safer and smoother.

Stop Shipping Blob Tokens: OIDC Is the Cleaner Deploy Secret

Nimesh Kulkarni — Tue, 02 Jun 2026 12:34:29 +0000

Ngl, one of the easiest ways to make a deployment pipeline sketchy is to give it a long-lived storage token and hope nobody ever leaks it.

That pattern is still everywhere: CI uploads static assets, build artifacts, screenshots, or user-facing files to some blob bucket, and the workflow stores a token in secrets.BLOB_TOKEN forever.

It works.

It also quietly creates a key that can outlive the job, the branch, the intern who created it, and sometimes the entire project. Big yikes.

The better pattern that keeps showing up across modern platforms is OIDC-based deploy auth: your CI job proves who it is, asks the provider for short-lived access, does the upload, and disappears.

The old flow

Most teams start here:

- name: Upload assets
  env:
    BLOB_TOKEN: ${{ secrets.BLOB_TOKEN }}
  run: npm run upload-assets

Simple, but the risk is obvious:

the token sits in your repo/org secrets forever
rotation becomes another chore nobody owns
leaked logs, compromised runners, or copied workflows can turn into real access
every workflow tends to get more permission than it actually needs

For a side project, maybe that feels acceptable. For production pipelines, it becomes tech debt with security vibes.

The OIDC flow

With OIDC, GitHub Actions or another CI provider can request an identity token for the current job. The cloud/storage platform verifies claims like repo, branch, environment, and workflow, then issues temporary credentials.

The workflow shape becomes closer to this:

permissions:
  id-token: write
  contents: read

jobs:
  upload:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Upload assets with short-lived auth
        run: npm run upload-assets

The actual provider setup differs, but the idea is the same: trust the workload identity, not a copied secret string.

This is why recent platform updates around OIDC for blob/storage workflows are worth paying attention to. They are not just “nice auth features.” They are a signal that deployment secrets are moving from static keys to verified, short-lived identity.

Why developers should care

This is not only a security-team thing.

OIDC makes day-to-day engineering cleaner:

fewer secrets to create, share, rotate, and audit
safer preview deployments from protected branches or environments
tighter permissions per repo/workflow instead of one mega-token
less panic when someone accidentally prints an env var in CI

Tbh, the best security improvements are the ones that remove a thing you had to remember. OIDC does exactly that.

A quick migration checklist

If your build uploads anything to blob storage, artifact storage, package registries, or cloud buckets, check this:

Is the workflow using a long-lived token?
Does the provider support OIDC or workload identity federation?
Can access be scoped by repo, branch, workflow, or environment?
Can the token be removed after the OIDC path works?

Do not migrate everything in one heroic PR. Pick one low-risk upload job, move it to OIDC, and document the pattern for the next workflow.

The takeaway

Long-lived deploy tokens were convenient when CI/CD was simpler.

But now that pipelines publish assets, trigger releases, talk to AI services, and touch production infra, “just store a token” is starting to look outdated.

If a platform gives you OIDC for deploy-time storage access, use it. Your future self will have one less secret to babysit — and that is a clean W.

Multi-Agent Code Reviews Need Pipelines, Not Vibes

Nimesh Kulkarni — Mon, 01 Jun 2026 12:36:23 +0000

Most teams are about to hit the same AI coding problem: one agent can write a lot of code, but it cannot be the only judge of its own work.

That is where multi-agent review starts to matter.

The next useful dev workflow is not “ask the model to be careful.” It is a pipeline where different agents own different checks, and boring deterministic tools still do the boring deterministic work.

The single-agent trap

A coding agent can implement a feature, update tests, and explain the diff. That is already powerful.

But if the same agent writes the code, reviews the architecture, checks security, decides whether tests are enough, and summarizes the risk, you are basically asking one intern to approve their own pull request.

That is not a workflow. That is optimism with a CLI.

A better pattern

Think of AI agents like specialized reviewers in your engineering loop:

Implementation agent: writes the first version of the change.
Test agent: looks for missing cases, edge conditions, and regression gaps.
Security agent: checks auth paths, secrets, injection risks, unsafe dependencies, and data exposure.
Architecture agent: watches for coupling, weird abstractions, and changes that fight the existing system.
Summary agent: turns the mess into one clean PR comment humans can actually use.

The point is not to add AI everywhere. The point is to stop pretending one model pass is enough.

CI is the control plane

The cleanest place to run this is still CI.

A practical pull request flow can look like this:

Run lint, type checks, unit tests, and build checks.
Trigger focused AI reviewers only after the deterministic checks finish.
Give each reviewer a narrow prompt and a narrow permission scope.
Collect findings into one review summary.
Escalate only the risky or uncertain parts to a human.

This keeps the workflow grounded. Traditional tools catch facts. Agents catch judgment-heavy issues.

MCP makes this easier, but also riskier

With MCP and similar tool layers, agents can access GitHub, CI logs, docs, issue trackers, observability tools, and internal systems through a standard interface.

That is exactly why the pattern is useful.

It is also exactly why permissions matter.

Start read-only. Log every tool call. Scope access to specific repos and workflows. Do not give an AI reviewer write access just because the demo looked clean. If it can comment on a PR, that is already useful. If it can merge, deploy, or mutate infrastructure, that needs a much higher bar.

The real upgrade

The future of AI coding is not one giant prompt that does everything.

It is smaller agents, clearer jobs, shared context, deterministic checks, and human attention saved for the decisions that actually need taste.

Multi-agent code review is not about replacing review culture.

It is about making review culture scale when AI starts generating more code than humans can comfortably inspect line by line.

Markdown Is Becoming the AI App Interface

Nimesh Kulkarni — Sun, 31 May 2026 12:35:12 +0000

A quiet developer pattern is getting louder: Markdown is becoming the interface layer for AI apps.

Microsoft's markitdown project has been trending because it solves a boring problem that keeps showing up in real products: how do you turn PDFs, Word files, slide decks, spreadsheets, and HTML pages into something an AI system can actually use?

The answer is not glamorous. Convert the mess into Markdown.

That sounds too simple, but it works because AI apps do not fail only at the model layer. They fail when the input is messy, hidden, lossy, or impossible to inspect.

Why Markdown keeps winning

Markdown has a boring superpower: everyone can read it.

A developer can open it in a terminal. Git can diff it. Static sites can render it. LLMs can follow headings, lists, code blocks, and links without needing a custom parser for every file type.

That makes Markdown a solid handoff format between real-world documents and AI workflows.

PDF / DOCX / PPTX / HTML
        ↓
Markdown
        ↓
cleanup + validation
        ↓
search, RAG, summaries, agents, docs

The important part is not "Markdown is cool." The important part is that Markdown gives your pipeline a visible middle layer.

If the output is bad, you can inspect the Markdown and see where the context broke.

The use case that matters

Imagine an internal AI assistant for a support or engineering team.

The source material is never clean. There are old onboarding docs, customer PDFs, policy pages, architecture notes, product specs, and random exports from tools nobody wants to maintain.

Without a common format, every file type becomes a separate problem.

With Markdown, the flow is simpler:

markitdown product-spec.pdf > product-spec.md

Then the app can clean it, split it by headings, index it, summarize it, or pass selected sections into an agent.

That is the real win. Markdown becomes the boring contract between messy documents and useful AI behavior.

Where this helps right now

This pattern is useful when teams want to:

turn support docs into searchable knowledge
feed architecture notes into coding agents
migrate old documents into a docs site
build lightweight internal knowledge bases
keep AI context auditable instead of hiding it inside a black-box parser

The last point matters. When an AI answer is wrong, the team needs to debug the context, not just blame the model.

If the context is Markdown, you can read it. You can diff it. You can fix it.

The trap

Conversion is not magic.

Tables can break. Scanned PDFs may need OCR. Images can disappear. Slide decks can lose structure. Footnotes can land in weird places.

So the pipeline should not be:

convert -> trust blindly -> ship

It should be:

convert -> validate -> normalize -> use

A small validation step saves a lot of weird AI behavior later.

Takeaway

Markdown is becoming more than a writing format. It is becoming a practical interface for AI apps.

Before adding another vector database, agent framework, or prompt trick, check the boring thing first: is the input clean, readable, and inspectable?

Most AI products get better when the context gets better. Markdown is one of the simplest ways to make that happen.