Comments URL: https://news.ycombinator.com/item?id=47605008

Points: 2

# Comments: 1

I'm Siddarth, co-founder at DrDroid. We build tooling for engineering teams to detect and debug production issues faster. Our product is an always-on autonomous AI agent that listens to alerts, investigates issues and escalates where necessary, before an engineer even picks them up.

While building that, we noticed something: our agent debugged issues significantly faster (and more accurately) when it had pre-built context about the infrastructure. Which services exist, which dashboards track what, what the DB schema looks like. Without it, agents spend the first stretch of every session re-exploring things they should already know. We kept hitting the same thing with Claude Code and Cursor internally when using it with MCP servers.

So we extracted that idea into droidctx, an open source CLI that connects to your production tools and generates structured .md files capturing your infrastructure. Run droidctx sync and it pulls metadata from Grafana, Datadog, Kubernetes, Postgres, AWS, and 20+ other connectors into a clean directory. Add one line to your CLAUDE.md pointing at that directory, and your agent starts every session already knowing your stack.

Outcome to expect: fewer tool calls, fewer hallucinations about your specific setup, and lesser context to share every time. We've had some genuinely surprising moments too. The agent once traced a bug to a specific table column by finding an exact Grafana query in the context files, something it wouldn't have known to look for cold.

It's MIT licensed and pre-built with 25 connectors across monitoring, Kubernetes, databases, CI/CD, and logs. It runs entirely locally. Credentials stay in credentials.yaml and never leave your machine.

Curious whether others have hit this problem with coding agents, and whether "generate context once, reuse across sessions" feels like the right abstraction or if we're solving this the wrong way. Happy to hear what's missing or broken.

Comments URL: https://news.ycombinator.com/item?id=47278068

Points: 2

# Comments: 0

This writeup explains how we designed Dynamic Memory Retrieval (DMR) — a multi-layered agentic search system over 80+ integrations (Grafana, Datadog, K8s, AWS, etc.) that indexes 200+ record types and enables the agent to iteratively discover and extract relevant context during production investigations.

Key takeaways: why keyword search outperformed embeddings for our domain, how we structure short-term vs long-term memory, and what it takes to make an agent reliably navigate a company's entire production stack.

Comments URL: https://news.ycombinator.com/item?id=46912048

Points: 2

# Comments: 1

After two years of iterating, we’ve built a solution that lets you check pod statuses, restart pods, run custom commands, or diagnose complex issues — all from Slack.

Why we built it:

We noticed SREs often spend a lot of time jumping between terminals, dashboards, and docs to diagnose K8s issues. Our goal is to bring debugging directly into your team’s workflow (i.e., Slack), guided by an AI assistant.

How it works:

Sign up Invite the bot to your Slack channel Connect your Kubernetes cluster Start chatting (e.g., Doctor droid restart unhealthy pods in cluster x)

Key features:

AI-driven assistance for diagnosing and troubleshooting Simple UI within Slack to check logs, restart pods, etc. Proxy option for clusters not publicly accessible (GitHub repo)

What’s next:

Expanding beyond K8s to 40+ cloud-native integrations (private beta live) Leveraging existing SOPs, docs, tribal knowledge (upcoming feature) Automating postmortems, documentation updates, and scripts

Free Credits:

Feedback is super valuable to us—please let us know what you think! Grab 500 free credits (worth $50) if you sign up before January 31.

Docs & more:

Docs: docs.drdroid.io ProductHunt: https://producthunt.com/

Who we’re looking for: Anyone dealing with K8s day-to-day—your feedback will shape our roadmap!

Thanks for checking it out. We’d love to hear your thoughts, critiques, or questions in the comments!

Comments URL: https://news.ycombinator.com/item?id=42729847

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=42308979

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=41425558

Points: 2

# Comments: 0

Also, some more researches in the similar space by other enterprises:

Microsoft: https://yinfangchen.github.io/assets/pdf/rcacopilot_paper.pd...

Salesforce: https://blog.salesforceairesearch.com/pyrca/

Personal plug: I'm building a self-service AIOps platform for engineering teams (somewhat similar to this work by Meta). If you're looking to read more about it, visit -- https://docs.drdroid.io/docs/doctor-droid-aiops-platform

Comments URL: https://news.ycombinator.com/item?id=41163640

Points: 1

# Comments: 0

We are a DevTool. We help engineers debug production issues faster. We do this thought our Open Source automation tooling for on-call and SRE engineers. We work with tech enterprises to help optimise their DevEx / On-Call routines.

Requirement: We are looking for someone with 1-2 years experience in production ML/LLM projects at growth stage startups or enterprises. They will primarily work on some of our tooling experiments -- you can see more of our experiments through the products section in the website.

We are a team of 5 engineers. We are a seed stage team, collaborating and ideating everyday at our office, also called casa-de-droid.

email siddarth [at] drdroid [dot] io if it sounds like a place you'd like to be a part of.

Comments URL: https://news.ycombinator.com/item?id=41119733

Points: 2

# Comments: 0

Saw their demo, didn't feel excited -- I'd rather use a chat assistant (in warp or gpt) I guess instead of doing natural language in the terminal

We deployed the change to make it intuitive (similar to what is suggested) yesterday. It's still in integration branch so awaiting merging in main on this.

> i thought perhaps it had executed the step, which the check mark indicating completion or success.

Noted.

> It wasn’t clear that it was an input box since it didn’t have focus, and it wasn’t clear that the check mark was a button.

Noted.

> It seems like it’s the “Data” field, although the name doesn’t make much sense.

It is indeed a dropdown list but we had hard-coded it for sandbox so user can't change the source of an existing step. It is changeable when you host your own version or when you add a new step in sandbox.

> There’s a “reload”(?) icon next to it, but I have no idea what that does.

In case user decides to add a new source on-the-go (say in another tab), reload helps fetch the same list again.

Overall, I do understand that some parts of it are unintuitive and is a focus area for us to improve it asap.

The runbooks are still codified by a human in the current scenario. We are experimenting with some data to see if we can generate accurate runbooks for different scenarios but haven't found much luck with it yet. I do think that some % of issues will be abstracted in near future with machines doing the healing automatically.

> you should invest in toil reduction to stop having those repeated problems.

Most teams I speak to say that they try their best to avoid repeating the same issue again. Users typically use PlayBooks for:

(a) A generic scenario where you have an issue reported / alerted and you are testing 3-4 hypotheses / potential failure reasons at once.

(b) You want to run some definitive sequence of steps.