DEV Community: Tommaso Bertocchi

OSINT Prompts for ChatGPT and Claude: 5 Templates and a Repeatable Method

Tommaso Bertocchi — Tue, 09 Jun 2026 18:12:20 +0000

Most people using AI for OSINT are doing it backwards.

They open ChatGPT or Claude, type "find everything on this email," and hope. The model produces something that looks confident, reads well, and is often wrong. No sourcing, no verification, no idea what it actually checked.

The problem isn't the model. It's the missing process behind the prompt. A language model with no structure will fill gaps with plausible text. An investigation is the opposite of that: it's the discipline of separating what you know from what you assume.

This post gives you a method and five prompt templates you can paste into ChatGPT, Claude, or any assistant today. They're written for authorized, public-source work only.

A note on ethics and scope, before anything else

OSINT means open-source intelligence: information that is publicly available and lawful to access. It does not mean breaking into accounts, scraping private data, social engineering, or surveilling people without authorization.

Every prompt below assumes you have a legitimate reason and the authority to run the investigation: your own assets, a client engagement with a signed scope, due diligence on a company, journalism, or a CTF. If you can't point to that authorization, stop. The fastest way to turn a research skill into a legal problem is to skip this step.

The method: scope, collect, pivot, verify, document

Good investigations are boring in the best way. They follow the same five phases regardless of the target:

scope    -> what am I authorized to do, and what answer do I need?
collect  -> gather public data from real sources
pivot    -> turn one data point into the next (email -> username -> domain)
verify   -> challenge every finding, rate confidence, kill assumptions
document -> a report someone else could reproduce

A model can help in every phase, but only if your prompt tells it which phase it's in. A prompt that says "investigate this" gets you a guess. A prompt that says "you are in the scoping phase, output only the plan" gets you something useful.

The five prompts

Paste these as-is. Replace the bracketed parts. Each one is built to keep the model honest about what it actually knows versus what it's inferring.

1. Scoping

Run this first, every time. It stops you from chasing the wrong thing.

You are an OSINT analyst in the SCOPING phase. Do not collect or guess any
data yet.

Engagement: [one line on what you are authorized to investigate]
Objective: [the specific question you need answered]

Output:
1. A restated objective in one sentence.
2. In-scope vs out-of-scope (sources, identifiers, targets).
3. The 3-6 concrete questions that, if answered, satisfy the objective.
4. The public source types relevant to each question.
5. Legal/ethical flags I should confirm before proceeding.

Ask me anything ambiguous instead of assuming.

2. Email as a starting point

An email rarely answers a question by itself. It's a seed you pivot from.

You are in the COLLECT and PIVOT phases. The seed is an email address:
[email]

List, as a checklist, the public-source checks worth running and what each one
could reveal:
- public breach/exposure datasets (presence only, no credential content)
- account discovery on public platforms tied to this address
- associated public profiles, avatars, and usernames
- domain of the email (if not a free provider) and what it implies

For each check, state: the data point it could produce, and the next pivot it
unlocks. Mark anything that requires live data I still need to fetch. Do not
fabricate results.

3. Username pivot across platforms

Usernames are the connective tissue of an identity online. Map them with confidence levels, not certainty.

You are in the PIVOT and VERIFY phases. Seed username: [handle]

Produce a table of public platforms where this handle may exist. For each:
- platform
- how to confirm the account is the same person (signals: bio, links, avatar,
  writing style, cross-links)
- confidence: high / medium / low / unconfirmed
- what would raise or lower that confidence

Be explicit that handle reuse is not proof of the same person. Flag every
inference as an inference.

4. Domain and infrastructure

This is the most clear-cut OSINT surface: infrastructure is meant to be public.

You are in the COLLECT phase. Target: [domain or IP]

Outline the public infrastructure checks and what each tells me:
- WHOIS / registration data and registrar
- DNS records (A, MX, NS, TXT) and what they reveal about hosting and email
- passive DNS and historically associated records
- related infrastructure (shared hosting, certificates, subdomains)
- hosting provider and ASN

For each, note the pivot it enables and whether I need to pull live data.
Output a structure I can drop findings into.

5. Verify and report

The phase everyone skips and the one that separates analysis from a vibe.

You are in the VERIFY and DOCUMENT phases. Here are my raw findings:
[paste findings]

Do three things:
1. For each finding, classify it as confirmed, probable, or assumption, and say
   what evidence supports it.
2. Attack the weakest links: what would make each finding wrong? What did I not
   check?
3. Produce a short report: objective, method, findings with confidence levels,
   gaps, and recommended next steps. Write it so another analyst could
   reproduce it.

Make the prompts pull real data instead of guessing

The honest limitation: a chat model alone cannot see live WHOIS, current DNS, or whether an account actually exists right now. It reasons; it doesn't fetch. That's why the prompts above keep saying "mark anything that requires live data."

To close that gap, connect the model to real sources. OpenOSINT is a free, open-source OSINT agent and MCP server built exactly for this: the model plans the investigation, then calls real tools (DNS, WHOIS, account discovery, IP intelligence, and more) so the answers come from data, not from the model's imagination.

pip install openosint

It runs as an interactive REPL, a CLI, an MCP server, or a small web UI, and works with Anthropic Claude or a local Ollama model. Repo and docs: https://github.com/OpenOSINT/OpenOSINT

With it connected, the prompts above stop being templates for guesswork and become an actual investigation loop: prompt -> tool call -> real data -> pivot -> verify.

Want the full set?

These five cover the backbone. A real engagement needs more: phone numbers, image clues, company due diligence, social footprint, structured reporting templates, and a tighter ethics and legal primer so your work stays authorized and public-source.

I packaged the 30+ prompts I actually use into one file: the AI OSINT Prompt Pack. It's a 7-page PDF, built to pair with OpenOSINT, with the full scope -> collect -> pivot -> verify -> document workflow baked into every prompt.

If the five above saved you time, the complete set is here: https://tommasodev.gumroad.com/l/ai-osint-prompt-pack?ref=devto

Either way, take the method with you. The tools change. The discipline of separating what you know from what you assume is what makes the work hold up.

10 Best AI Agents for 2026

Tommaso Bertocchi — Fri, 05 Jun 2026 15:55:45 +0000

Every few weeks another "best AI agents" list appears. Most of them are the same six projects in a different order, with the same GitHub screenshots and the same copy-pasted descriptions.

This isn't that.

I put this together based on actual community traction, architectural decisions that matter, and honest answers to the question: would a working developer actually reach for this when shipping something real?

The criteria I used:

does it actually act autonomously, or just autocomplete?
is there real 2026 momentum — commits, contributors, production usage?
can you deploy it without three days of config?
does it have a coherent architecture, or is it just wrappers all the way down?
does it solve a problem that's genuinely hard without it?

This list covers ten projects. They don't all look the same, which is the point — the agent ecosystem in 2026 is plural, not monolithic.

TL;DR: the best agents in 2026 are the ones that made a hard architectural call and stuck with it. Generalist everything-frameworks are losing to focused tools that do one thing without apology.

OpenOSINT — Claude-native AI agent for OSINT and security research
Browser-Use — The browser automation layer the whole ecosystem builds on
OpenHands — The open-source answer to Devin
LangGraph — Production-grade stateful agent orchestration
CrewAI — Multi-agent teams that actually ship work
Letta — The agent framework that solved memory
smolagents — Hugging Face's code-first, zero-bloat agent framework
Dify — The LLM app platform with 80K+ stars and a serious workflow engine
SWE-agent — Princeton's coding agent with a clean Agent-Computer Interface
MetaGPT — Simulates an entire software company in your terminal

1) OpenOSINT — Claude-native AI agent for OSINT and security research

What it is: An open-source AI-powered OSINT terminal agent built natively on Claude's Tool Use API — not retrofitted, not a wrapper, architecturally native.

Why it matters in 2026: There's a category of AI agent that exists because the workflow genuinely needs it, and security research is the clearest example. Recon is repetitive, cross-source, and time-sensitive — exactly the class of problem agents should be solving. OpenOSINT doesn't pretend to be a general assistant. It's a domain-specific agent for OSINT workflows: IP lookups, domain intelligence, breach data, threat correlation, all orchestrated through Claude's structured tool calls. The MCP-native architecture means it plugs into the modern AI toolchain without friction. If you work in security, threat intelligence, or are building on top of Claude's Tool Use API, this is a reference implementation worth studying. Check out openosint.tech.

Best for: OSINT workflows, security reconnaissance, threat intelligence, developers building domain-specific agents on Claude.

Links: GitHub

2) Browser-Use — The browser automation layer the whole ecosystem builds on

What it is: A Python library that gives AI agents a real browser — not a scraper, not a headless fetcher, an actual Chromium instance they can see, click, type into, and reason about.

Why it matters in 2026: 93K+ GitHub stars. YC W25. Their own fine-tuned models. A marketplace with 1,200+ community automations. At this point, Browser-Use isn't a library — it's the de facto substrate for web-capable agents. The core architectural insight was obvious in retrospect: scraping is brittle because the web isn't static. Agents that can render pages, interact with JavaScript, and handle dynamic content are an order of magnitude more capable than anything that pattern-matches HTML. Browser-Use made that the default. Every other framework that wants to interact with the web either builds on top of it or reinvents it poorly.

Best for: web automation, research pipelines, form filling, any agent that needs to interact with the live web rather than parse static HTML.

Links: GitHub

3) OpenHands — The open-source answer to Devin

What it is: An autonomous AI software engineering platform — formerly OpenDevin — that writes code, runs tests, fixes bugs, and opens pull requests inside a sandboxed Docker environment.

Why it matters in 2026: OpenHands began as a community-driven response to Cognition's Devin. It raised $18.8M Series A and reached 70K+ GitHub stars with meaningful contributions from engineers at AMD, Apple, Google, Amazon, Netflix, and NVIDIA — not just indie hackers. The difference between OpenHands and a code autocomplete tool is the CodeAct agent: it doesn't propose a change, it makes the change, runs the tests, reads the output, and iterates. A 72% SWE-Bench score is competitive with proprietary alternatives that charge enterprise prices. Supports 100+ LLM backends including local models via Ollama. MIT license.

Best for: autonomous code generation, GitHub issue resolution, brownfield codebase work, engineering automation without a cloud vendor.

Links: GitHub

4) LangGraph — Production-grade stateful agent orchestration

What it is: A graph-based agent orchestration framework from LangChain — built specifically for cycles, branching, and persistent state across multi-step agent workflows.

Why it matters in 2026: Most agent frameworks model execution as a linear chain. Real agents aren't linear — they loop, they branch, they pause and resume, they handle interrupts and human-in-the-loop confirmations. LangGraph's graph-first execution model maps directly to how production agents actually behave. State is a first-class citizen: every node reads from and writes to a typed state object, which means you can checkpoint, replay, and debug any point in the execution. The 2025 Platform release added deployment infrastructure on top of the core framework, turning it from a library into something you can actually run at scale. If your agent workflow is genuinely complex, LangGraph is the honest choice.

Best for: multi-step agent workflows, stateful agent pipelines, human-in-the-loop systems, any scenario where linear chains break down.

Links: GitHub

5) CrewAI — Multi-agent teams that actually ship work

What it is: A framework for orchestrating role-based teams of AI agents that collaborate on complex tasks — independently of LangChain and with a clear production focus.

Why it matters in 2026: The mental model is intuitive and it turns out that matters: give each agent a role and a goal, assemble them into a crew, let them delegate. 44K+ stars and 5.2 million monthly downloads suggest the abstraction resonated. CrewAI is strongest in business workflow automation — content pipelines, lead qualification, customer support, research synthesis — where the natural structure of the work maps well to a team of specialists. The streaming tool call events added in January 2026 fixed the main complaint that held teams back from production deployment. 82% task success rate, sub-2-second average latency in benchmarks.

Best for: multi-agent collaboration, business process automation, content pipelines, role-based task delegation.

Links: GitHub

6) Letta — The agent framework that solved memory

What it is: Formerly MemGPT — an open-source agent framework from UC Berkeley that gives LLMs a layered memory system modeled after OS virtual memory, letting agents maintain coherent state across unlimited context.

Why it matters in 2026: The context window problem was always misframed. The real issue isn't length — it's that agents forget. Letta's approach is architectural: a tiered memory system where in-context memory, recall storage, and archival storage interact through explicit read/write operations. The agent controls what it remembers. This makes Letta the right tool for long-running agents — customer-facing assistants, research companions, anything where the conversation history is measured in days or weeks rather than turns. The rename from MemGPT to Letta in late 2024 came with a production server, REST API, and multi-user support. MIT license.

Best for: persistent agents, long-running workflows, stateful assistants, applications where memory is a core product requirement.

Links: GitHub

7) smolagents — Hugging Face's code-first, zero-bloat agent framework

What it is: A minimal agent framework from Hugging Face where agents write and execute Python instead of parsing JSON tool schemas — removing the abstraction layer between the model and the action.

Why it matters in 2026: The framework bloat problem in the agent space is real. Before you run your first task in most frameworks, you've configured tool schemas, defined graph nodes, and learned a DSL that only exists inside that library. smolagents skips it. The agent writes Python. Python runs. You read what happened. That's the whole model. The tradeoff — less abstraction, more visibility — is exactly right for developers who want to actually understand their agent's behavior, not just watch it produce outputs. Hugging Face backing means first-class model hub integration and natural support for local open-weight models.

Best for: fast prototyping, local model workflows, developers who want minimal surface area, Hugging Face ecosystem integrations.

Links: GitHub

8) Dify — The LLM app platform with 80K+ stars and a serious workflow engine

What it is: An open-source LLM application development platform with a visual workflow builder, RAG pipeline, agent runtime, model management layer, and observability tooling — all in one self-hostable package.

Why it matters in 2026: Dify is what happens when you build for the team that ships the product, not just the engineer who prototypes it. The visual workflow editor lets non-engineers modify agent logic without touching code. The RAG pipeline is production-ready with chunking strategies, embedding model choices, and retrieval tuning built in. The observability layer — traces, token costs, performance metrics — is the thing that actually matters when you're running agents in production and something goes wrong at 2am. 80K+ GitHub stars across a genuinely global contributor base. Apache 2.0 license.

Best for: production LLM apps, RAG pipelines, teams mixing technical and non-technical contributors, anyone who needs agent observability out of the box.

Links: GitHub

9) SWE-agent — Princeton's coding agent with a clean Agent-Computer Interface

What it is: A coding agent from the Princeton NLP group that formalizes agent-codebase interaction through a structured Agent-Computer Interface (ACI), designed around real GitHub issue resolution.

Why it matters in 2026: SWE-agent made a deliberate architectural choice that most frameworks avoided: instead of giving the agent unrestricted shell access, it built a constrained, purpose-fit interface — specific tools for editing files, running tests, navigating codebases — and found that the constraints improved performance. The Agent-Computer Interface concept has since influenced how most serious coding agents are designed. This is the project researchers and practitioners use when they want to understand what's happening inside the agent loop rather than just see outputs. Actively maintained by the Princeton NLP group, MIT license.

Best for: software engineering research, SWE-Bench work, coding agent experimentation, developers who want to inspect the agent internals.

Links: GitHub

10) MetaGPT — Simulates an entire software company in your terminal

What it is: A multi-agent framework that assigns structured SOP roles — product manager, architect, engineer, QA — to LLMs and runs them through the actual process a software team would follow, from a one-line requirement to runnable code.

Why it matters in 2026: The core thesis of MetaGPT — Code = SOP(Team) — is more interesting than it sounds. Software isn't just code; it's the output of a structured process involving constraints, tradeoffs, and documentation. MetaGPT replicates that process in code and gets surprisingly coherent outputs: user stories, competitive analysis, data models, API specs, and working implementations that trace back to the original requirement. Crossed 50K GitHub stars. The MGX platform launched in early 2025 makes the multi-agent team interactive — you can direct it mid-execution rather than just watching it run.

Best for: automated spec generation, architecture documentation, complex planning pipelines, multi-role task decomposition.

Links: GitHub

Final thoughts

One pattern cuts across every project on this list: the ones that made a hard architectural call early are outperforming the ones that tried to be everything.

Browser-Use decided agents need real browsers. Letta decided memory is an OS problem. LangGraph decided execution graphs matter more than chains. smolagents decided the framework should disappear. OpenOSINT decided domain-specificity beats general-purpose. In every case, the constraint produced clarity.

What the 2026 agent ecosystem looks like from this list:

specialization beats generality in almost every real-world deployment
observability is now table stakes — if you can't trace what your agent did, you can't run it in production
memory is an architecture problem, not a context window problem
sandboxed execution is non-negotiable for any coding agent
the OSINT/security category is real and underserved — AI-native tooling here is early and high-leverage
local AI is the assumed baseline, not a niche configuration

The best agent stack in 2026 is probably a combination of two or three of these — not one framework to rule them all.

What's your pick for the most underrated agent project heading into the second half of 2026?

10 Best Open-Source AI Agents for 2026

Tommaso Bertocchi — Tue, 26 May 2026 19:08:55 +0000

Most "best AI agents" lists are just whatever showed up on Hacker News last month.

This one is different.

I picked these projects based on actual usage patterns, real GitHub momentum, and whether they solve a problem you'd plausibly care about in 2026 — not because they have a nice landing page.

I'm ranking these by a mix of:

genuine autonomy — does it actually act, or just suggest?
momentum in 2026 — commits, contributors, real community
real-world deployability — can you ship it, or just demo it?
architectural clarity — is it built around a solid idea, or just hype wrapped in Python?
whether any actual developer would reach for it in a real project

If you build software, run automations, care about local AI, or want to see where the agent ecosystem is actually heading, this is the list.

TL;DR: 2026 is the year autonomous agents stopped being demos and started being infrastructure — pick your stack carefully.

OpenOSINT — Terminal-first AI agent for security research
Hermes Agent — Self-hosted agent that learns the longer it runs
OpenClaw — Your personal AI in every app you already use
OpenHands — The open-source answer to Devin
Browser-Use — Give AI agents a real browser and watch what happens
CrewAI — Multi-agent teams that actually ship work
AutoGPT — The pioneer that grew up into a real platform
MetaGPT — Simulates an entire software company in your terminal
SWE-agent — Princeton's coding agent with a clean Agent-Computer Interface
smolagents — Hugging Face's code-first, zero-bloat agent framework

1) OpenOSINT — Terminal-first AI agent for security research

What it is: An open-source AI-powered OSINT terminal agent built natively on Claude's Tool Use API.

Why it matters in 2026: Security research tooling is one of the few areas where AI agents have a genuinely justified reason to exist — the workflows are repetitive, data-heavy, and benefit directly from automation. OpenOSINT takes that seriously: it's built around Claude's Tool Use API from the ground up, not bolted on. That means the agent doesn't just query things — it actually reasons through reconnaissance tasks using structured tool calls. It represents a growing category of AI-powered security research tooling that's open-source, terminal-native, and designed for developers who care about how the underlying plumbing works. Find it at openosint.tech.

Best for: OSINT workflows, security reconnaissance, threat intelligence gathering, developers building on top of Claude's Tool Use API.

Links: GitHub

2) Hermes Agent — Self-hosted agent that learns the longer it runs

What it is: An open-source autonomous AI agent by Nous Research with persistent cross-session memory and a self-improving skills system.

Why it matters in 2026: The star explosion is the signal, not the product. What makes Hermes Agent interesting is the self-improving skills system — it builds on its own past actions to get better at recurring tasks, not just session to session but permanently. It runs on any Linux server, connects to Telegram, Discord, Slack, WhatsApp, and Signal out of the box, and has a migration path directly from OpenClaw. 2026 is the year Hermes went mainstream — it crossed the threshold from an impressive research project to something teams are actually running in production. By Nous Research, MIT license.

Best for: personal automation, self-hosted always-on agents, persistent memory workflows, developers who want an agent that compounds over time.

Links: GitHub

3) OpenClaw — Your personal AI in every app you already use 🦞

What it is: A personal AI assistant gateway — built by Peter Steinberger — that connects LLMs to your own devices and apps through messaging platforms you already use.

Why it matters in 2026: 374K+ stars and still climbing. OpenClaw isn't trying to give you another chat UI — it's built around the idea that your personal agent should live where you already spend time: WhatsApp, Telegram, Signal, Discord, iMessage, and more. Molty 🦞, the lobster mascot, has become a symbol of the local-first agent movement. The local gateway model is the right architectural bet for people who care about privacy and control — you run it, you own it, it answers through the apps you already have open. It became the fastest GitHub repo to reach 100K stars in history. MIT license.

Best for: personal automation, messaging-based AI workflows, local-first assistants, power users, privacy-conscious setups.

Links: GitHub

4) OpenHands — The open-source answer to Devin

What it is: An autonomous AI software engineering platform — formerly OpenDevin — that writes code, runs tests, fixes bugs, and opens pull requests inside a sandboxed Docker environment.

Why it matters in 2026: OpenHands started as a community response to Cognition AI's Devin announcement. It has since raised $18.8M in Series A funding and reached 70K+ GitHub stars with contributions from engineers at AMD, Apple, Google, Amazon, Netflix, and NVIDIA. The CodeAct agent doesn't just suggest edits — it executes them, checks the results, and iterates. A 72% SWE-Bench score puts it at or above proprietary alternatives on real-world software engineering benchmarks. Supports 100+ LLM providers including local models via Ollama. MIT license.

Best for: autonomous coding, GitHub issue resolution, legacy codebase migration, software engineering automation, self-hosted Devin alternative.

Links: GitHub

5) Browser-Use — Give AI agents a real browser and watch what happens

What it is: A Python library that makes websites accessible for AI agents, letting any LLM drive a real browser to complete web-based tasks.

Why it matters in 2026: 93K+ stars and a YC W25 batch later, Browser-Use has become the default open-source answer to the question "how does my agent interact with a website." The architectural bet is simple and correct: agents need a real browser, not a scraper. They've since trained their own models specifically optimized for browser automation, built a marketplace with 1,200+ community automations, and shipped a cloud layer on top of the MIT-licensed core. It's the browser automation layer the whole agent ecosystem is building on top of.

Best for: web automation, AI-driven form filling, scraping, research pipelines, any agent workflow involving the open web.

Links: GitHub

6) CrewAI — Multi-agent teams that actually ship work

What it is: A framework for orchestrating role-based teams of AI agents that collaborate on complex tasks — independently of LangChain.

Why it matters in 2026: CrewAI's mental model clicked for a lot of developers: define agents with roles and goals, assemble them into a crew, and let them delegate to each other. 44K+ stars and 5.2 million monthly downloads later, it's one of the most-used agent frameworks among teams building real automations — content pipelines, sales prospecting, lead qualification, customer support. The January 2026 addition of streaming tool call events fixed the biggest production-readiness complaint. It achieves an 82% task success rate in benchmarks with sub-2-second average latency.

Best for: multi-agent collaboration, content generation pipelines, business process automation, role-based task delegation.

Links: GitHub

7) AutoGPT — The pioneer that grew up into a real platform

What it is: The project that started the modern autonomous AI agent movement — now a mature platform with a visual builder, an agent marketplace, and self-hosting via Docker.

Why it matters in 2026: AutoGPT is the most-starred project in the AI agent category on GitHub. Most people think of it as the 2023 demo that burned through GPT-4 credits. That version is gone. What exists in 2026 is a full platform with a block-based visual builder, a marketplace of pre-packaged agents, and production-grade self-hosting. Every serious agent framework that came after AutoGPT either built on its ideas or reacted against them. You can't understand the 2026 agent landscape without knowing where it started.

Best for: general-purpose automation, visual agent building, non-developer teams, experimentation, multi-step task workflows.

Links: GitHub

8) MetaGPT — Simulates an entire software company in your terminal

What it is: A multi-agent framework that assigns SOP roles — product manager, architect, engineer — to LLMs and simulates the full process of a software company from a one-line requirement.

Why it matters in 2026: MetaGPT crossed 50K GitHub stars and has earned it. The core idea is unusual and worth taking seriously: Code = SOP(Team) — meaning software is the output of structured processes, and if you replicate those processes in code you get surprisingly coherent results. It takes a requirement as input and outputs user stories, competitive analysis, data structures, API specs, and actual code. The MGX (MetaGPT X) platform launched in early 2025 extends this into a collaborative agent dev team you can direct interactively.

Best for: automated software spec generation, architecture documentation, complex planning pipelines, multi-role task decomposition.

Links: GitHub

9) SWE-agent — Princeton's coding agent with a clean Agent-Computer Interface

What it is: A research-born coding agent from Princeton that introduces a structured Agent-Computer Interface (ACI) for interacting with codebases, designed specifically for real-world GitHub issue resolution.

Why it matters in 2026: Where OpenHands went for enterprise-grade platform features, SWE-agent went the other direction — minimal footprint, clean interface, rigorous benchmarks. The Agent-Computer Interface concept it pioneered — standardizing how agents interact with shells, editors, and test runners — has influenced how almost every serious coding agent is designed today. It's the framework researchers and serious practitioners reach for when they want to understand what's actually happening inside the agent loop. MIT license, actively maintained by the Princeton NLP group.

Best for: software engineering research, SWE-Bench benchmarking, coding agent experimentation, developers who want to understand the internals.

Links: GitHub

10) smolagents — Hugging Face's code-first, zero-bloat agent framework

What it is: A minimal, code-first agent framework from Hugging Face where agents write and execute Python instead of calling JSON tool definitions — keeping the whole thing readable and debuggable.

Why it matters in 2026: The agent framework space has a bloat problem. Most frameworks require you to define tools as JSON schemas, configure graph nodes, and learn a framework-specific DSL before you can do anything. smolagents skips all of that. Agents write Python, Python runs, you see what happened. The Hugging Face backing means it has first-class integration with the model hub, Inference Endpoints, and the broader open-source model ecosystem. If you're running local models and want the smallest possible surface area between your code and the agent loop, smolagents is the honest choice.

Best for: quick prototyping, local model workflows, Hugging Face ecosystem integrations, developers who hate framework complexity.

Links: GitHub

Final thoughts

If I had to summarize the AI agent space in 2026 with one sentence, it would be this:

the gap between "demo" and "production" is finally closing, and the projects that close it fastest are the ones that don't try to do everything.

The best agents in this list share a pattern: they picked a specific problem, built a clean interface around it, and shipped. That's why Browser-Use at 93K stars and smolagents with almost no surface area can both belong on the same list.

What these projects collectively represent:

specialization over generality — purpose-built agents beat general-purpose frameworks in almost every real use case
local AI as the default — not a niche setup, but the expected option
messaging apps as agent interfaces — WhatsApp and Telegram are becoming agent shells
sandboxed execution — no serious coding agent ships without isolated environments
open benchmarks — SWE-Bench scores are the new leaderboard
the OSINT and security category is real — AI-native tooling for security research is no longer a gap

The agent ecosystem in 2026 isn't one thing. It's a set of independently useful primitives that you can assemble based on what you actually need.

What's your #1 pick for the best AI agent in 2026?

I built an MCP-native OSINT framework that lets AI agents investigate from your terminal

Tommaso Bertocchi — Mon, 25 May 2026 10:11:55 +0000

You give Claude a single prompt — "investigate this email address" — and it autonomously chains five tools: email enumeration, username search across 300+ platforms, breach lookup, WHOIS, and IP geolocation. No manual invocations, no copy-pasting output between scripts, no babysitting. That's what OpenOSINT enables, and it works because the entire tool surface is exposed through the Model Context Protocol.

What is OpenOSINT?

OpenOSINT is a Python framework that acts as an MCP server, exposing 9 OSINT tools to any MCP-compatible AI client — Claude Code, Claude Desktop, or anything else that speaks the protocol. It is not a scraper, not a dashboard, not a GUI. It is a structured tool surface that lets LLMs call real intelligence-gathering utilities the same way they call any other function.

The framework wraps proven OSINT tools — holehe, sherlock, sublist3r, phoneinfoga, HaveIBeenPwned — in async, stateless Python functions that the MCP layer can discover and invoke.

Version 2.1.0 is live on PyPI, the repo is MIT-licensed, and it runs on Python 3.10+. If you know what OSINT is but have never had an AI agent drive an investigation autonomously, this is the fastest path to that experience.

Why MCP?

The Model Context Protocol is an open standard for connecting AI assistants to external tools and data sources. Instead of writing a custom function-calling wrapper for every LLM provider, you implement an MCP server once — define your tools, their input schemas, their descriptions — and any MCP-compatible client can discover and use them automatically.

For OSINT tooling, this matters. Before MCP, you had two options: hard-code investigation logic into a prompt (fragile, unmaintainable) or build a custom agent that calls tools via a provider-specific function-calling API (works, but locked to one provider and one integration pattern). With MCP, you expose OSINT capabilities as a server once, and every compatible client — Claude Code, Claude Desktop, or any future client — can drive investigations autonomously.

There's prior art here. A freeCodeCamp article explored building an autonomous OSINT agent using the Claude Tool Use API directly. OpenOSINT takes that concept and makes it protocol-native: the tools are not hard-wired to Claude's API, they're available to any MCP client. The result is that the same 9 tools work regardless of which AI client you're using, and you don't rewrite the integration every time the ecosystem changes.

The practical payoff: once your MCP server is registered, you stop thinking about which tool to call. You describe the investigation goal, and the agent decides which tools to chain, in what order, based on what it finds at each step.

The 9 Tools

Tool	What it does	External dependency
`search_email`	Email account enumeration	holehe
`search_username`	Username search across 300+ platforms	sherlock
`search_breach`	Data breach check	HaveIBeenPwned v3 API
`search_whois`	WHOIS domain registration lookup	python-whois
`search_ip`	IP geolocation + ASN	ipinfo.io
`search_domain`	Subdomain enumeration	sublist3r
`generate_dorks`	Generates 12 targeted Google dork URLs	none (no network calls)
`search_paste`	Pastebin dump search	psbdmp.ws
`search_phone`	Phone carrier + country + line type	phoneinfoga binary

Three tools worth showing in detail:

search_email runs an email address through holehe to check which online accounts are registered to it:

openosint search-email target@example.com

[+] twitter.com        → registered
[+] github.com         → registered
[-] instagram.com      → not found
[+] spotify.com        → registered

search_username passes the username to sherlock and checks 300+ platforms:

openosint search-username johndoe42

[+] GitHub     → https://github.com/johndoe42
[+] Reddit     → https://reddit.com/user/johndoe42
[+] Twitter    → https://twitter.com/johndoe42
[-] TikTok     → not found

search_ip queries ipinfo.io and returns geolocation, ASN, and organization data:

openosint search-ip 8.8.8.8

IP:           8.8.8.8
Hostname:     dns.google
City:         Mountain View
Region:       California
Country:      US
Organization: AS15169 Google LLC
ASN:          AS15169

Architecture

OpenOSINT has three strict layers with one architectural rule: no layer imports from a layer above it.

Layer	Path	Responsibility
Core tools	`openosint/tools/`	Async wrappers — stateless, no I/O, no UI
MCP server	`openosint/mcp_server.py`	Translates tools to MCP schemas, handles stdio transport
CLI	`openosint/cli.py`	Human-facing interface, formats output for the terminal

The core tools layer is where all the actual work happens. Each tool is a stateless async function that accepts typed inputs and returns structured data. It knows nothing about how it's being called. The MCP server layer reads those functions and exposes them as MCP tool definitions with JSON schemas. The CLI layer calls the same functions directly and handles terminal rendering.

This separation is what makes the MCP and CLI modes interchangeable. The same search_email async function runs whether Claude is calling it via MCP or you're typing a command in your terminal. No duplication, no drift between the two interfaces, no special-casing.

Installation

Clone the repo and install in editable mode:

git clone https://github.com/OpenOSINT/OpenOSINT.git
cd OpenOSINT
pip install -e .

Install the external OSINT dependencies:

pip install holehe sherlock-project sublist3r
# phoneinfoga: download the binary from its GitHub releases page
# and ensure it's available on your PATH

To register OpenOSINT as an MCP server in Claude Code:

claude mcp add openosint python /absolute/path/to/OpenOSINT/openosint/mcp_server.py
claude mcp list

For Claude Desktop, add the server entry to your claude_desktop_config.json:

{
  "mcpServers": {
    "openosint": {
      "command": "python",
      "args": ["/absolute/path/to/OpenOSINT/openosint/mcp_server.py"]
    }
  }
}

Restart Claude Desktop after saving. On next launch it will discover all 9 tools automatically — no further configuration needed.

Agentic OSINT in action

This is the use case that makes the MCP architecture worth it. Open Claude Code and type:

claude

Then give it a single prompt:

Investigate target@example.com. If you find an associated username,
trace it across other platforms and compile a full report.

Here's what happens internally, without any further input from you:

Claude calls search_email with target@example.com
The tool returns a list of platforms where the email is registered — including a recognizable username pattern
Claude calls search_username with that username
sherlock checks 300+ platforms and returns all profile URLs
Claude calls search_breach to check if the email has appeared in known data breaches
Claude synthesizes all results into a structured investigation report

No manual tool invocation. No copy-pasting output between commands. The agent decides the investigation path based on what it finds at each step. If search_email returns nothing actionable, it pivots — tries generate_dorks, calls search_whois, or runs search_paste. That's the difference between a collection of OSINT scripts and a tool surface that an agent can reason over.

Optional: Breach + Phone Intel

Two tools require additional setup to return full results.

search_breach uses the HaveIBeenPwned v3 API, which requires a paid API key for programmatic access. Set it as an environment variable before running:

export HIBP_API_KEY=your_key_here

Once set, search_breach returns breach metadata for an email address:

target@example.com found in 3 breaches:
- LinkedIn (2012) — 164M accounts — passwords, emails
- Adobe (2013) — 153M accounts — passwords, emails, usernames
- Dropbox (2012) — 68M accounts — passwords, emails

search_phone wraps the phoneinfoga binary, which must be on your PATH. You can optionally set IPINFO_TOKEN for enriched geolocation data on top of the carrier lookup:

export IPINFO_TOKEN=your_token_here

Example output:

Phone:     +14155552671
Country:   United States
Carrier:   AT&T Mobility
Line type: mobile

Both tools degrade gracefully if env vars are missing — search_breach returns a clear permissions error from the API, and search_phone falls back to basic carrier data. The rest of the framework continues working regardless.

What's next

The current tool set covers the core OSINT surface well, but the obvious next directions are more tools and tighter workflows. Near-term additions that would fit naturally: a search_certificate tool for certificate transparency log lookups (an underused source of subdomain and org data), a search_social tool for public social metadata aggregation, and piped workflow support so you can chain tools in a single CLI command without needing an AI client at all.

Longer term, a lightweight web UI that acts as an MCP client would make OpenOSINT accessible to teams who aren't running Claude Code. As more AI clients adopt the protocol, the value of the MCP architecture compounds — every new compatible client gets all 9 tools for free. If you want to add a tool, the contribution surface is clear: write a stateless async function in openosint/tools/, and the MCP server and CLI will pick it up automatically. Open an issue with your idea first, or submit a PR directly.

Star the repo if it's useful: https://github.com/OpenOSINT/OpenOSINT.

Wrapping up

OpenOSINT is what happens when you stop treating OSINT tools as standalone scripts and start treating them as a structured capability surface for AI agents. The Model Context Protocol makes that surface discoverable, composable, and client-agnostic. You get nine real tools, a clean three-layer architecture, and agentic investigation workflows that chain those tools autonomously based on what they find.

Install it, register the MCP server, and give Claude something to investigate. The half-hour setup is worth it.

GitHub: https://github.com/OpenOSINT/OpenOSINT
Website: https://openosint.tech/
PyPI: https://pypi.org/project/openosint/

OpenOSINT is for legal and authorized use only. Users are responsible for compliance with applicable laws in their jurisdiction.

I Built an AI-Powered OSINT Agent That Investigates Targets Autonomously — From Your Terminal

Tommaso Bertocchi — Thu, 21 May 2026 08:58:14 +0000

Legal disclaimer: OpenOSINT is intended for legal and authorized use only — penetration testing with permission, investigating your own accounts, journalistic research. Users are solely responsible for compliance with applicable law. See DISCLAIMER.md.

You type a target. An AI agent decides which tools to run. It chains them based on findings. It writes you a structured report. You never touch a prompt.

That's OpenOSINT.

I've been building this since early this year and just hit v2.12.0. The project started as a simple MCP server wrapping a handful of OSINT binaries. It's grown into something I actually use daily: a full agentic OSINT framework with a terminal REPL, a web UI, a direct CLI, and full MCP server support for Claude Code and Claude Desktop.

Let me walk you through what it does and how it works.

What Is OpenOSINT?

OpenOSINT is a modular OSINT framework with three interfaces that share the same 11-tool core:

Interface	How to invoke	What it is
AI REPL	`openosint`	Claude-powered terminal. Type targets in natural language. Agent decides what to run.
Direct CLI	`openosint email addr`	Run individual tools without AI, for scripting or quick lookups.
MCP Server	registered via `claude mcp add`	Exposes all 11 tools to any MCP-compatible client (Claude Code, Claude Desktop).

The framework is written in Python, built on asyncio, uses prompt_toolkit + Rich in the REPL, and the AI layer talks to Anthropic's native tool use API directly.

No embedded model. No output massaging. When the agent issues a tool call, the real binary executes and real stdout goes back. Hallucination in tool results is structurally impossible.

The 11 Tools

Tool	Backend	What it finds
`search_email`	holehe	Social accounts linked to an email (Spotify, Gravatar, Office365…)
`search_username`	sherlock	Accounts across 300+ platforms
`search_breach`	HaveIBeenPwned v3 API	Data breach exposure, leaked data types
`search_whois`	python-whois	Domain registrant, registrar, creation/expiry dates
`search_ip`	ipinfo.io	Geolocation, ASN, hostname
`search_ip2location`	IP2Location API	Enhanced geolocation + VPN/Proxy/Tor/datacenter detection
`search_domain`	sublist3r	Subdomain enumeration
`generate_dorks`	built-in	12 targeted Google dork URLs (no network call)
`search_paste`	psbdmp.ws	Pastebin dump mentions
`search_phone`	phoneinfoga	Carrier, country, line type
`search_censys`	Censys API	Open ports, services, certificate history

If a binary is absent from PATH, that tool returns a descriptive error — the rest of the framework keeps running.

The AI REPL

This is my favourite part. Run openosint with no arguments and you land in an interactive session powered by the Anthropic tool use API.

openosint ❯ investigate target@example.com

  → generate_dorks('target@example.com')
  → search_email('target@example.com')
  ✓ Found: Spotify, WordPress, Gravatar, Office365

  → search_breach('target@example.com')
  ✓ Found in 2 breaches: LinkedIn (2016), Adobe (2013)

  ╭──────────────── Report ────────────────╮
  │ ## Summary                             │
  │ Single target — high confidence.       │
  │                                        │
  │ ## Online Presence                     │
  │ Spotify · WordPress · Gravatar         │
  │                                        │
  │ ## Data Breaches                       │
  │ LinkedIn (2016) · Adobe (2013)         │
  ╰────────────────────────────────────────╯

  ✓ Report saved → reports/2026-05-11_report.md

You don't have to specify which tools to run. Type a natural language instruction and the agent figures it out:

investigate target@example.com → email + breach + dorks
find all accounts for johndoe99 → username search across 300+ platforms
what subdomains does example.com have? → domain tool
check if +14155552671 is mobile → phone tool

Reports are auto-saved after every investigation containing structured findings. Available REPL commands:

Command	Description
`clear`	Reset conversation memory
`save`	Save last report to `reports/`
`tools`	List available tools and their status
`config`	Show current configuration
`exit` / Ctrl-D	Exit

The Web Interface

The website (openosint.tech) ships with full documentation in the classic man(1) style. But there's also a local web UI — a browser-based AI chat interface with real-time streaming, tool result cards, and light/dark theme.

pip install "openosint[web]"
openosint web
# → opens automatically at http://localhost:8080

Features:

AI chat with inline tool results
Full conversation history per session
Light/dark theme (preference saved in browser)
Ollama support — run it with local models, no API key required
API key management via Settings modal

A hosted version at openosint.tech/app is coming soon.

MCP Server Mode

This was actually the original reason I built the project. OpenOSINT exposes all 11 tools to any MCP-compatible client. Once registered, you can run full autonomous OSINT investigations directly from Claude Code without leaving your editor.

Claude Code:

claude mcp add openosint python /absolute/path/to/OpenOSINT/openosint/mcp_server.py
claude mcp list

Claude Desktop — add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "openosint": {
      "command": "python",
      "args": ["/absolute/path/to/OpenOSINT/openosint/mcp_server.py"]
    }
  }
}

Then from Claude Code:

> Investigate target@example.com. If you find an associated username,
  trace it across other platforms and compile a full report.

The model issues tool calls natively. No prompting tricks. No wrappers.

Architecture

The internal layering is strict and intentional:

Layer	Path	Responsibility
Core tools	`openosint/tools/`	Async wrappers around external binaries and APIs. Stateless.
AI agent	`openosint/agent.py`	Anthropic tool use loop. Maintains conversation history per session.
REPL	`openosint/repl.py`	Interactive terminal session. prompt_toolkit + Rich.
MCP server	`openosint/mcp_server.py`	MCP tool schema exposure for external AI clients.
CLI	`openosint/cli.py`	Entry point. Launches REPL or dispatches direct commands.

No layer imports from a layer above it. The core tools have zero knowledge of MCP, argparse, or the agent loop. This makes each surface independently testable and the whole thing easy to extend.

Installation

git clone https://github.com/OpenOSINT/OpenOSINT.git
cd OpenOSINT
pip install -e .
export ANTHROPIC_API_KEY=sk-ant-...

External dependencies (must be in PATH):

pip install holehe sherlock-project sublist3r
# phoneinfoga: download binary from https://github.com/sundowndev/phoneinfoga/releases

Optional environment variables:

Variable	Tool	Purpose
`HIBP_API_KEY`	`search_breach`	HaveIBeenPwned API key
`IPINFO_TOKEN`	`search_ip`	ipinfo.io token (higher rate limits)
`IP2LOCATION_API_KEY`	`search_ip2location`	IP2Location API key

A Note on Design

The most interesting architectural decision was keeping the AI agent completely out of the tool layer. The tools are dumb — they wrap a binary or API call, enforce a timeout, and return a string. The agent is the only thing that knows about conversation history, tool chaining, and report generation.

This means you can use the CLI for quick scripting without pulling in any AI overhead, and the same code powers both the REPL and the MCP server.

The other thing I'm proud of is the timeout enforcement. Every external subprocess gets a hard timeout. If holehe or sherlock hangs on a slow platform, the tool aborts cleanly and returns a partial result rather than blocking the whole session.

What's Next

Hosted web app at openosint.tech/app — currently running locally only
More tools (suggestions welcome via GitHub Issues)
Ollama tool use support in the REPL (partially implemented)

Why Every AI+Security Tool I Tried Was Lying to Me (And What I Built Instead)

Tommaso Bertocchi — Mon, 18 May 2026 16:13:50 +0000

TLDR: I built an open source AI agent that runs OSINT investigations from your terminal. The interesting part wasn't the OSINT — it was figuring out why every approach I tried kept hallucinating security data, and how I fixed it using the Anthropic tool use API.

I'm Tommaso Bertocchi, a developer and open source creator. I also maintain Pompelmi, a file upload security scanner for Node.js with 600+ GitHub stars.

Here is a real output I got from an AI OSINT tool six months ago:

[+] Twitter: @targethandle
[+] GitHub: https://github.com/megadose/holehe
[+] IP Address: 80.249.165.118
[+] SSH Banner: SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
[+] Organization: Unnamed Organization (United States)

Every single line was invented.

The Twitter handle didn't belong to the target. The GitHub link was the whole repo itself. The IP, the SSH banner, the organization — pure hallucination, formatted to look exactly right.

This is the problem with combining LLMs and security tooling naively. Models are trained to produce plausible-looking output. Security data is highly structured and pattern-consistent. So when a model doesn't know something, it invents something that looks exactly right — and that's far more dangerous than an obvious error.

I spent three months building, breaking, and rebuilding an approach that actually works. This is what I learned.

The Wrong Way: Manual ReAct Loop

The obvious first approach is a ReAct (Reasoning + Acting) loop. You prompt the model to output JSON when it wants to call a tool, parse it, execute the tool, feed results back, repeat.

# The naive approach
response = llm.chat(messages)
if "tool_call" in response:
    tool_name = parse_json(response)["tool"]
    result = run_tool(tool_name)
    messages.append(result)
    response = llm.chat(messages)

The problem: the model generates both the tool call and mentally "simulates" what the tool would return — all in one forward pass. By the time you feed real results back, the model has already committed to a narrative. It reconciles the real output with its hallucinated expectations rather than updating cleanly.

I tried every prompt engineering fix:

"NEVER invent results" — ignored
"Copy tool output VERBATIM" — model still reworded and added context
"If you have no data, say 'No results found'" — model said "No results found" then listed fake results anyway

The model was roleplaying an OSINT analyst, not executing one.

The Right Way: Native Tool Use API

The Anthropic tool use API changes the architecture fundamentally.

Instead of asking the model to generate tool calls as text, you define tools as structured schemas. The model returns stop_reason: "tool_use" — a hard stop. Your code executes the actual tool. The real output goes back as a tool_result block. The model continues.

while True:
    response = client.messages.create(
        model="claude-sonnet-4-20250514",
        max_tokens=4096,
        system=SYSTEM_PROMPT,
        tools=tool_definitions,
        messages=messages
    )

    # Model is done — return final response
    if response.stop_reason == "end_turn":
        return response.content[0].text

    # Model wants a tool — execute it for real
    if response.stop_reason == "tool_use":
        messages.append({"role": "assistant", "content": response.content})
        tool_results = []

        for block in response.content:
            if block.type == "tool_use":
                # This is the critical part: real execution, real output
                result = TOOL_MAP[block.name](**block.input)
                tool_results.append({
                    "type": "tool_result",
                    "tool_use_id": block.id,
                    "content": result
                })

        messages.append({"role": "user", "content": tool_results})

The model never gets a chance to simulate results because it hits a hard stop before generating them. It receives real output before continuing. Hallucination becomes structurally impossible in the tool output path.

The Architecture: OpenOSINT

I built this into OpenOSINT — an open source AI OSINT agent for the terminal.

Three layers, cleanly separated:

1. Provider layer — abstracts the LLM. Same interface for Anthropic, OpenAI, and Ollama:

class BaseProvider(ABC):
    @abstractmethod
    def chat(self, messages: list, system: str, tools: list) -> ProviderResponse:
        pass

2. Tool registry — OSINT tools registered via decorator:

@register_tool(
    name="search_email",
    description="Find social accounts linked to an email using holehe.",
    parameters={
        "type": "object",
        "properties": {
            "email": {"type": "string"}
        },
        "required": ["email"]
    }
)
def search_email(email: str) -> str:
    result = subprocess.run(["holehe", email], capture_output=True, text=True, timeout=60)
    found = [l.strip() for l in result.stdout.splitlines() if "[+]" in l]
    return "Found:\n" + "\n".join(found) if found else "No accounts found."

3. Agent loop — the ReAct loop using native tool use, described above.

Adding a new tool is one file + one decorator. Nothing else to touch.

The Tools

Tool	Wraps	What it investigates
`search_email`	holehe	Social accounts linked to an email
`search_username`	sherlock	300+ platforms by username
`search_domain`	sublist3r	Subdomain enumeration
`search_breach`	HaveIBeenPwned API	Data breach exposure
`search_whois`	python-whois	Domain registrant info
`search_ip`	ipinfo.io	Geolocation, ASN, hostname
`generate_dorks`	built-in	Google dork URL generation
`search_paste`	psbdmp	Pastebin dump mentions
`search_phone`	phoneinfoga	Carrier, country, line type

Why the Agent Approach Beats a Fixed Pipeline

The alternative to an agent is a hardcoded workflow: always run holehe, then sherlock, then HIBP. Simple, predictable, debuggable.

The problem: different targets need different workflows.

An email address → holehe + breach check makes sense. A domain → WHOIS + sublist3r makes sense. A person's name with no other identifiers → generate dorks first to discover real usernames, then run Sherlock on those. Running Sherlock on "John Doe" directly is useless.

The agent figures this out. It reads what generate_dorks returns, finds a mention of @johndoe_dev on GitHub in the dork output, and runs search_username("johndoe_dev") — not search_username("John Doe").

This is the actual value of the agent: not automation, but contextual decision-making. Each step informs the next.

Multi-Provider Support

The provider abstraction means you can swap the LLM without touching anything else:

# config.yaml
provider: anthropic  # or: openai, ollama
model: claude-sonnet-4-20250514
api_key: sk-ant-...

OpenAI's function calling works on the same principle as Anthropic's tool use, so it slots in cleanly. Ollama (local models) is marked experimental — local models handle structured tool-calling less consistently, but it works for basic investigations without sending data to any API.

What a Real Investigation Looks Like

openosint ❯ investigate john.doe@example.com

⠸ Investigating...

→ generate_dorks    john.doe@example.com
✓ Generated 10 dork URLs

→ search_email      john.doe@example.com
✓ Found: spotify, wordpress, gravatar, office365

→ search_breach     john.doe@example.com
✓ Found in 2 breaches: LinkedIn (2016), Adobe (2013)

→ search_paste      john.doe@example.com
✗ No results

╭──────────────────── Report ─────────────────────╮
│ ## Ambiguity Check                               │
│ Single target identified — high confidence.      │
│                                                  │
│ ## Online Presence                               │
│ Spotify · WordPress · Gravatar · Office365       │
│                                                  │
│ ## Data Breaches                                 │
│ LinkedIn (2016) · Adobe (2013)                   │
│                                                  │
│ ## Conclusion                                    │
│ Moderate footprint. Credential rotation          │
│ advisable given breach exposure.                 │
╰──────────────────────────────────────────────────╯

✓ Report saved → reports/2025-05-08_john-doe.md

Everything in that report came from actual tool output. Nothing invented.

Get Started

pip install openosint
openosint config    # interactive setup — picks provider, validates API key
openosint investigate "john.doe@example.com"

Full source: github.com/OpenOSINT/OpenOSINT

MIT License. For authorized security research use only — read DISCLAIMER.md.

What I'd Do Differently

If I rebuilt this today:

Parallel tool execution. Right now, tools run sequentially. There's no reason search_email and search_breach can't run concurrently when the agent wants both. Adds complexity to the message threading but worth it for speed.

Confidence scoring. The agent should annotate findings with a confidence level — "found via direct tool output" vs "inferred from dork results." Different epistemic weight.

Streaming output. The Rich terminal renders the full report at the end. It should stream token-by-token so large reports feel instant.

Originally published on HackerNoon.

I built an AI agent that does OSINT investigations automatically

Tommaso Bertocchi — Sun, 17 May 2026 17:10:07 +0000

Most OSINT workflows look the same.

holehe → copy username → sherlock → browser for HIBP → WHOIS tab → take notes → repeat.

Every tool is a silo. Every pivot is manual.

I built OpenOSINT to fix that.

You type a target. The agent chains the tools, pivots on what it finds, and saves a structured report. No manual switching.

9 tools out of the box: holehe, sherlock (300+ platforms), HaveIBeenPwned, WHOIS, ipinfo, sublist3r, phoneinfoga, Pastebin dumps, Google dorks.

The key design decision: uses Anthropic's native tool use API so the model never generates tool results — it only reads real output from real binaries. Hallucination is structurally impossible.

Also ships as an MCP server for Claude Code / Claude Desktop. Supports Ollama for local models — no API key required.

MIT license. Python 3.10+. Authorized use only.

⭐ github.com/OpenOSINT/OpenOSINT

I built an AI agent that runs autonomous OSINT investigations from your terminal

Tommaso Bertocchi — Mon, 11 May 2026 13:58:36 +0000

You know the OSINT workflow. Open a terminal. Run holehe against an email. Copy a username you found. Switch tools. Run sherlock. Open a browser. Check HaveIBeenPwned manually. Pull up a WHOIS tab. Take notes. Repeat.

Every tool is a silo. Every pivot is manual. The investigation logic lives entirely in your head.

I wanted to fix that.

What I built

OpenOSINT is an open-source Python framework with an AI agent at its core. You describe a target in natural language — an email address, a username, a domain, an IP, a phone number — and the agent decides which tools to run, chains them based on what it finds, executes everything against the real binaries, and compiles a structured Markdown report.

Three interfaces:

Interactive AI REPL (default) — type natural language, agent chains the tools autonomously
Direct CLI — run individual tools directly, no AI, perfect for scripting
MCP Server — expose all 9 tools to Claude Code or Claude Desktop

The demo

Here's a real session. No mocking. The agent receives an email, runs discovery, extracts a username, pivots to search it across 300+ platforms, checks breaches, and saves a report — all unchained:

$ openosint
openosint ❯ investigate target@example.com

  → generate_dorks('target@example.com')
  → search_email('target@example.com')
  ✓ Found: Spotify, WordPress, Gravatar, Office365

  → search_breach('target@example.com')
  ✓ Found in 2 breaches: LinkedIn (2016), Adobe (2013)

  → search_username('target_handle')
  ✓ Found on: GitHub, Reddit, HackerNews, Twitter

  ╭──────────────── Report ────────────────╮
  │ ## Summary                             │
  │ Single target — high confidence.       │
  │                                        │
  │ ## Online Presence                     │
  │ Spotify · WordPress · Gravatar         │
  │                                        │
  │ ## Data Breaches                       │
  │ LinkedIn (2016) · Adobe (2013)         │
  ╰────────────────────────────────────────╯

  ✓ Report saved → reports/2026-05-11_report.md

The agent went email → accounts → username pivot → cross-platform search → breach check. No human orchestration.

The architecture

The codebase has three layers with a hard no-upward-import rule:

Layer	Path	Responsibility
Core tools	`openosint/tools/`	Async wrappers around binaries and APIs. Stateless. No AI.
AI agent	`openosint/agent.py`	Anthropic tool use loop. Per-session conversation history.
Interfaces	`repl.py`, `mcp_server.py`, `cli.py`	REPL, MCP server, direct CLI.

The AI layer is optional. The core tools run fine without it — the CLI and MCP server both bypass the agent entirely.

Why hallucination in tool results is structurally ruled out

The AI layer uses the Anthropic native tool use API. Here's the exact flow:

Agent receives your prompt
Model decides which tool to call → issues a hard stop
Real binary executes (holehe, sherlock, etc.)
Real output goes back into the context as a tool_result
Model reads actual output, decides next step

The model never infers or synthesizes what a tool would return. It only ever sees real output. If sherlock finds 47 profiles, that exact number and those exact URLs go back. The agent can't make up results because it never generates them.

9 tools

Tool	Backend	What it finds
`search_email`	holehe	Social accounts linked to an email
`search_username`	sherlock	Accounts across 300+ platforms
`search_breach`	HaveIBeenPwned v3	Breach exposure and leaked data types
`search_whois`	python-whois	Registrant, registrar, creation/expiry dates
`search_ip`	ipinfo.io	Geolocation, ASN, hostname, org
`search_domain`	sublist3r	Subdomain enumeration
`generate_dorks`	built-in	12 targeted Google dork URLs (no network calls)
`search_paste`	psbdmp.ws	Pastebin dump mentions
`search_phone`	phoneinfoga	Carrier, country, line type

If a dependency is missing, that tool returns a descriptive error and the rest keeps running.

Installation

git clone https://github.com/OpenOSINT/OpenOSINT.git
cd OpenOSINT
pip install -e .
export ANTHROPIC_API_KEY=sk-ant-...

External deps (via pip):

pip install holehe sherlock-project sublist3r

phoneinfoga is a standalone binary — download from GitHub releases.

Optional env vars:

export HIBP_API_KEY=your_key     # HaveIBeenPwned v3
export IPINFO_TOKEN=your_token   # higher rate limits on ipinfo.io

Requires Python 3.10+.

Using it

Interactive REPL

$ openosint
openosint ❯ investigate target@example.com
openosint ❯ find all accounts for johndoe99
openosint ❯ what subdomains does example.com have?
openosint ❯ check if +14155552671 is a mobile number

Reports are auto-saved to reports/ as Markdown after every investigation containing structured findings.

REPL commands:

clear     Reset conversation memory
save      Save last report manually
tools     Show available tools and status
config    Show current configuration
help      All commands
exit      Quit

Direct CLI (no AI)

openosint email target@example.com -t 60
openosint username johndoe99
openosint -v email target@example.com   # verbose

MCP Server

All 9 tools are exposed as an MCP server. Register in Claude Code:

claude mcp add openosint python /absolute/path/to/OpenOSINT/openosint/mcp_server.py
claude mcp list   # verify

Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "openosint": {
      "command": "python",
      "args": ["/absolute/path/to/OpenOSINT/openosint/mcp_server.py"]
    }
  }
}

Then from Claude Code:

> Investigate target@example.com. If you find a linked username,
  trace it across other platforms and compile a full report.

The agent chains exactly as it would in the REPL, but driven by Claude Code's context.

How the agent loop works (for the curious)

# Simplified version of openosint/agent.py

messages = [{"role": "user", "content": user_input}]

while True:
    response = anthropic.messages.create(
        model="claude-opus-4-5",
        tools=TOOL_SCHEMAS,   # all 9 tools as JSON schemas
        messages=messages
    )

    if response.stop_reason == "end_turn":
        break  # agent is done

    if response.stop_reason == "tool_use":
        tool_results = []
        for block in response.content:
            if block.type == "tool_use":
                # Execute the REAL binary
                result = await execute_tool(block.name, block.input)
                tool_results.append({
                    "type": "tool_result",
                    "tool_use_id": block.id,
                    "content": result   # real output, no inference
                })

        # Feed real results back into context
        messages.append({"role": "assistant", "content": response.content})
        messages.append({"role": "user", "content": tool_results})

The loop runs until stop_reason == "end_turn". The agent decides when it has enough information to write the report.

What's next

Shodan and Censys integration
Support for additional LLM providers (Ollama, GPT-4)
JSON and PDF export formats
Docker image for zero-setup deployment
Async parallel tool execution for multi-target investigations

Legal

OpenOSINT is for authorized security research, penetration testing, and investigative journalism only. Users are solely responsible for compliance with applicable law including GDPR, CCPA, and the CFAA. See DISCLAIMER.md.

GitHub: github.com/OpenOSINT/OpenOSINT
Docs: openosint.tech

Stars and issues welcome. If you build something with it, drop a comment — curious what use cases people find.

I built an AI agent that does OSINT investigations from your terminal

Tommaso Bertocchi — Fri, 08 May 2026 13:07:52 +0000

Most OSINT tools are great at one thing. You run holehe for emails, sherlock for usernames, sublist3r for domains. But you're the one deciding the workflow, switching between tools, copy-pasting results.

I wanted to remove that middle layer. So I built OpenOSINT — you describe a target in plain English, the AI figures out what to investigate and how, runs the tools, and hands you a report.

How it works

The core idea is simple: instead of hardcoding a fixed pipeline, I use Claude's native tool use API to let the model decide at each step what to do next based on what it found so far.

you ❯ investigate john.doe@gmail.com

→ search_email(john.doe@gmail.com)
  Found: spotify, wordpress, office365, gravatar

→ search_breach(john.doe@gmail.com)
  Found: 2 breaches (LinkedIn 2016, Adobe 2013)

→ search_paste(john.doe@gmail.com)
  No results.

✓ Report saved to reports/2025-05-08_john-doe.md

No hardcoded sequence. The model sees the holehe results and decides whether to check breaches next, look up the domain, or go straight to the report. It's a genuine reasoning loop, not a fixed script.

Why native tool use matters

The first version I built used a manual ReAct loop — I was parsing JSON from the model, extracting tool calls, running them, feeding results back. It worked but it was fragile. Models hallucinate tool results when they're bored.

With the Anthropic tool use API, the model returns stop_reason: "tool_use" when it wants to call something. You execute it, return the result, and the model continues. The loop is clean:

def run(self, prompt: str) -> str:
    messages = [{"role": "user", "content": prompt}]

    while True:
        response = self.provider.chat(
            messages=messages,
            system=SYSTEM_PROMPT,
            tools=self.tool_registry.get_definitions()
        )

        if response.stop_reason == "end_turn":
            return response.content

        if response.stop_reason == "tool_use":
            messages.append({"role": "assistant", "content": response.raw_content})

            results = []
            for call in response.tool_calls:
                result = self.tool_registry.execute(call.name, call.input)
                results.append({
                    "type": "tool_result",
                    "tool_use_id": call.id,
                    "content": result
                })

            messages.append({"role": "user", "content": results})

The model never gets a chance to invent results because it always receives the actual tool output before continuing.

Tools included

Tool	What it wraps	What it finds
`search_email`	holehe	social accounts linked to an email
`search_username`	sherlock	accounts across 300+ platforms
`search_domain`	sublist3r	subdomains
`search_breach`	HaveIBeenPwned API	data breach exposure
`search_whois`	python-whois	domain registrant info
`search_ip`	ipinfo.io	geolocation, ASN, hostname
`generate_dorks`	built-in	Google dork URLs for any target
`search_paste`	psbdmp API	Pastebin dump mentions
`search_phone`	phoneinfoga	carrier, country, line type

Each tool handles missing dependencies gracefully — if sherlock isn't installed it tells you the install command instead of crashing.

Multi-provider

The AI layer is completely swappable. On first run you pick your provider:

Select provider:
  [1] Anthropic (Claude) — Recommended
  [2] OpenAI (GPT-4o)
  [3] Ollama (Local) — Experimental

The same agentic loop runs regardless. Anthropic is noticeably better at following structured tool-use instructions, but all three work. Local models via Ollama are marked experimental because they're inconsistent with JSON-structured responses.

The terminal UI

Built with Rich. Tool calls log inline as they happen so you can see the investigation unfold in real time rather than waiting for a final dump.

openosint ❯ investigate john.doe@example.com

  ⠸ Investigating...

  → search_email          john.doe@example.com
  ✓ Found: spotify, wordpress, gravatar, office365

  → search_breach         john.doe@example.com
  ✓ Found in 2 breaches

  ╭──────────────────── Report ─────────────────────╮
  │ ## Ambiguity Check                              │
  │ Single target identified — high confidence.     │
  │                                                 │
  │ ## Online Presence                              │
  │ Confirmed: Spotify, WordPress, Gravatar,        │
  │ Office365                                       │
  │                                                 │
  │ ## Data Breaches                                │
  │ LinkedIn (2016), Adobe (2013)                   │
  ╰─────────────────────────────────────────────────╯

  Report saved → reports/2025-05-08_john-doe.md

Install

pip install openosint
openosint config    # runs the setup wizard
openosint investigate "john.doe@example.com"

Or from source:

git clone https://github.com/OpenOSINT/OpenOSINT
cd OpenOSINT
pip install -e .
openosint config

What's next

Web UI (optional, for non-terminal users)
Export to PDF
Graph visualization of connections between identifiers
More tools: LinkedIn scraping, GitHub profile analysis, image metadata

Reminder: OpenOSINT is for authorized use only. Read DISCLAIMER.md before using.

Source: github.com/OpenOSINT/OpenOSINT

8 Tools Powering the Fastest-Growing Startups in 2026

Tommaso Bertocchi — Wed, 06 May 2026 12:05:58 +0000

Most "startup stack" articles are written by people who haven't shipped anything in two years.

They'll tell you: Next.js, Prisma, Vercel, Supabase, done. That's the 2022 answer.

The startups gaining traction right now are making different choices — edge-native, serverless-first, zero-lock-in choices that weren't available or production-ready three years ago.

This isn't a list of "cool tools." It's the actual infrastructure decisions that let a 3-person team scale to 100k users without hiring a DevOps engineer.

How I selected these

I'm not ranking by GitHub stars or Twitter buzz. My criteria:

Ships fast — can a solo dev go from zero to deployed in under a day?
Edge or serverless-native — no single-region Node servers pretending to be modern
Doesn't own your data — open-source core or real self-host options
TypeScript-first DX — type errors at build time, not at 2am in production
Solves something boring that used to require a dedicated hire — security, background jobs, auth

TL;DR: The fastest startups in 2026 aren't using the default stack — they're building on edge-native, serverless-first tools that make a 3-person team feel like 10.

giphy.com

Hono — The API framework that actually runs at the edge
Neon — Serverless Postgres that branches like Git
Drizzle ORM — The TypeScript ORM that doesn't fight your database
Trigger.dev — Background jobs that don't require a PhD in distributed systems
shadcn/ui — UI components you copy, own, and never regret
pompelmi — The one security layer most early-stage startups skip
OpenNext — Escape Next.js infrastructure lock-in
Supabase — The open-source BaaS that didn't make you regret it later

1) Hono — The API framework that actually runs at the edge

What it is: A tiny (~14kB), ultra-fast web framework that runs identically on Cloudflare Workers, Bun, Deno, AWS Lambda, and Node.js.

Why it matters in 2026: Most API frameworks were designed for a single-region server. Hono was designed for a world where your function runs in 300 locations simultaneously. When cold starts are zero and latency is single-digit milliseconds globally, the old pattern of running Express in us-east-1 starts looking embarrassing. The ergonomics are close enough to Express that migration isn't a rewrite — it's an afternoon.

Best for: API-first products, edge-deployed backends, developers escaping Express or Fastify who don't want to give up familiar routing.

Links: GitHub | Website

2) Neon — Serverless Postgres that branches like Git

What it is: Fully managed, serverless Postgres with instant database branching — one command and you have an isolated copy of your database for any PR or experiment.

Why it matters in 2026: The "prod data leaking into staging" problem doesn't need to exist anymore. Neon's branching model means every preview deployment gets its own database copy, spun up in seconds, torn down automatically — no more shared staging databases everyone's afraid to touch. Scale-to-zero billing means pre-revenue startups aren't paying for idle Postgres at 3am.

Best for: Early-stage startups, teams using Vercel/Railway preview environments, developers who want managed Postgres without the AWS RDS tax.

Links: GitHub | Website

3) Drizzle ORM — The TypeScript ORM that doesn't fight your database

What it is: A TypeScript ORM with a SQL-like query API, zero dependencies, and first-class support for Postgres, MySQL, SQLite, and edge runtimes.

Why it matters in 2026: Prisma is excellent until it isn't — complex joins, raw migrations, or edge deployments all eventually expose its limits. Drizzle's philosophy is "SQL is the interface, TypeScript is the wrapper" — you write queries that look like SQL and the types fall out automatically. In an era where AI-generated code constantly hits ORM edge cases, having a predictable mental model matters more than magic.

Best for: TypeScript-first teams, developers deploying to Cloudflare Workers or Bun, anyone who's hit Prisma's migration drift at least once.

Links: GitHub | Website

Happy New Year Celebration GIF by Faith Holland - Find & Share on GIPHY

Discover & share this Happy New Year Celebration GIF by Faith Holland with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

4) Trigger.dev — Background jobs that don't require a PhD in distributed systems

What it is: An open-source platform for creating long-running background jobs in TypeScript — with built-in retries, scheduling, fan-out, and a real-time observability dashboard.

Why it matters in 2026: Every startup eventually needs background jobs: send emails, process uploads, sync external APIs, generate AI content. The default move is still "throw it in a queue and hope." Trigger.dev gives you durable, observable, type-safe background execution with the same DX as writing a regular function — no SQS configuration, no dead-letter queue archaeology. With LLM workloads now routinely taking 30–120 seconds, having a real background job platform isn't optional anymore.

Best for: Startups running AI pipelines, teams replacing Inngest or raw SQS queues, developers who want background jobs that don't silently fail at 4am.

Links: GitHub | Website

5) shadcn/ui — UI components you copy, own, and never regret

What it is: A collection of accessible, composable UI components built on Radix UI and Tailwind — installed by copying source code directly into your project, not by adding a package dependency.

Why it matters in 2026: Most component libraries eventually become a cage. shadcn/ui's model is radical: the code lives in your repo, you own it completely, and upgrading is opt-in and surgical. With AI-assisted UI development accelerating, having full source access means LLMs can actually modify your components correctly — not guess at a black-box library's undocumented internals.

Best for: Startups building internal tools or customer-facing dashboards, developers on Next.js or Remix who want full design control without writing Radix from scratch.

Links: GitHub | Website

giphy.com

6) pompelmi — The one security layer most early-stage startups skip

What it is: A minimal Node.js wrapper around ClamAV that scans any file and returns a typed Verdict (Clean, Malicious, ScanError). No daemons, no cloud, no native bindings, zero runtime dependencies.

Why it matters in 2026: User-generated content is everywhere, and every startup with a file upload is one malicious PDF away from a security incident. In a world where AI-generated malware is getting harder to detect, dropping a local ClamAV scan into your upload pipeline costs 10 lines of code and potentially saves your entire reputation. Most early-stage security checklists skip file scanning because it sounds hard — pompelmi makes it a 5-minute integration.

Best for: Startups accepting file uploads from users, SaaS products handling sensitive documents, developers who want server-side file validation without adding a cloud scanning service to their vendor list.

Links: GitHub

7) OpenNext — Escape Next.js infrastructure lock-in

What it is: An open-source adapter that deploys Next.js anywhere — Cloudflare Workers, AWS Lambda, Deno Deploy — not just Vercel.

Why it matters in 2026: Vercel is excellent, but "excellent" shouldn't mean "only option." Next.js became so tightly coupled to Vercel's infrastructure that deploying elsewhere felt like reverse engineering — OpenNext changes that by properly implementing the missing adapter layer. For startups with data residency requirements or cost concerns at scale, having a real self-hostable path for Next.js changes the architecture conversation entirely.

Best for: Startups evaluating multi-cloud or hybrid deployments, teams hitting Vercel's pricing at scale, developers who need Next.js but can't accept single-cloud lock-in.

Links: GitHub | Website

8) Supabase — The open-source BaaS that didn't make you regret it later

What it is: An open-source Firebase alternative — Postgres, real-time subscriptions, auth, storage, and edge functions, all in one platform with a self-hostable option.

Why it matters in 2026: Firebase's lock-in cost finally caught up with enough startups that "Firebase alternative" became a real product category. Supabase won that category by building on Postgres instead of a proprietary database — meaning your data model is portable from day one and the entire SQL ecosystem just works. With vector extensions, branching support, and a maturing edge functions story, Supabase in 2026 is not the scrappy Firebase clone it was in 2020.

Best for: Full-stack teams that want to move fast without infrastructure babysitting, startups that need auth + database + storage without stitching three separate services together.

Links: GitHub | Website

giphy.com

Final thoughts

The best startup stacks in 2026 were built for a world where compute is cheap, cold starts are unacceptable, and a 2-person team needs to move like a 20-person team.

That's why the tools actually winning right now are built around:

Edge-native execution as the default, not an afterthought
Type safety all the way from schema to frontend component
Open-source cores with managed hosting options — not one or the other
Security baked in early, before an incident forces the conversation
Boring infrastructure decisions made once, not revisited every quarter

The "default stack" gets you started. These tools get you to scale without burning out your team or your runway.

If I missed something obvious, drop it in the comments.

What's the one tool in your stack you'd refuse to build a startup without?

9 Open-Source Tools to Own Your Stack (and Kill Your Cloud Bills) in 2026

Tommaso Bertocchi — Tue, 05 May 2026 09:59:50 +0000

Most "self-hosting" articles are basically a list of Docker Compose files.

They tell you what to run. They don't tell you why the smart money is moving away from managed cloud services — or what a real production stack looks like when you do it right.

The shift isn't about being cheap. It's about control.

Your data. Your pipeline. Your infra. No vendor lock-in, no surprise pricing changes, no terms-of-service update that kills your product overnight.

Here's the stack I'd build today if I were starting from scratch — tools that are production-grade, actively maintained, and built by teams who eat their own cooking.

How I picked these

I'm not ranking by GitHub stars or Hacker News upvotes. I'm ranking by:

Production-readiness — does it hold up under real load, or is it a weekend project with a pretty README?
Migration story — can you replace an existing paid service without a 3-month rewrite?
Maintenance burden — how much ops work does it create vs. eliminate?
Privacy posture — does it send anything home? Telemetry, usage data, silent pings?
Community momentum — growing or stagnating?

TL;DR: In 2026 you can run a full production stack on cheap VPS hardware and own everything from auth to analytics to AI inference — the cloud is a choice, not a requirement.

giphy.com

Ollama — Run any LLM locally, one command
Coolify — Deploy apps without touching AWS or Vercel
Plausible — Analytics that don't spy on your users
Authentik — Auth without the $300/month Auth0 invoice
Forgejo — Git hosting that's actually yours
pompelmi — File scanning without sending files to the cloud
Meilisearch — Search that doesn't bill per query
Windmill — Automate workflows without Zapier's pricing ceiling
Netdata — Real-time monitoring without Datadog sticker shock

giphy.com

1) Ollama — Run any LLM locally, one command

What it is: A runtime that lets you download and run open-weight LLMs (Llama 3, Mistral, Gemma, Phi-4, DeepSeek) on your own hardware with a single CLI command.

Why it matters in 2026: Every app is getting an AI feature bolted on, and most teams are routing everything through OpenAI — which means user prompts, internal documents, and sensitive data are leaving your infrastructure constantly. Ollama changes the threat model entirely. Your inference stays local. No API key, no usage ceiling, no per-token bill that scales into a surprise. With Apple Silicon and consumer NVIDIA cards getting faster every cycle, "local LLM" has crossed the threshold from demo to production-viable for most workloads.

Best for: privacy-sensitive apps, teams building on open-weight models, developers who want zero inference cost during iteration.

Links: GitHub | Website

2) Coolify — Deploy apps without touching AWS or Vercel

What it is: A self-hostable PaaS that handles deployments, SSL, reverse proxying, database provisioning, and environment management — a full Heroku/Vercel replacement you run on your own VPS.

Why it matters in 2026: Vercel's pricing restructure and Render's new limits made a lot of teams do the math. A $6/month Hetzner VPS running Coolify handles most indie projects better than $50/month on a managed platform. The interface is clean, deployment from Git is one-click, and it handles Docker Compose natively. The difference from older self-hosted PaaS tools (Dokku, CapRover) is that Coolify actually feels finished.

Best for: indie hackers, small agencies, teams that want Heroku UX on their own hardware.

Links: GitHub | Website

giphy.com

3) Plausible — Analytics that don't spy on your users

What it is: A lightweight, privacy-first web analytics tool that gives you pageviews, referrers, and traffic sources — without cookies, without GDPR banners, without sending data to Google.

Why it matters in 2026: GA4 is still a compliance headache and a UX nightmare. More critically, a growing segment of users actively block Google Analytics. Plausible's tracker is under 1KB and so privacy-respecting that it loads on pages where GA4 gets blocked. Self-hosted, your data never leaves your server. You get cleaner numbers, not inflated by bot traffic that GA4 struggles to filter.

Best for: GDPR-conscious teams, devs building privacy-first products, anyone who tried GA4 onboarding and immediately wanted to quit.

Links: GitHub | Website

4) Authentik — Auth without the $300/month Auth0 invoice

What it is: A self-hosted identity provider and SSO platform that supports OAuth2, SAML, LDAP, and SCIM — a full Auth0/Okta alternative you run in a Docker container.

Why it matters in 2026: Auth0's free tier got gutted, and Okta's breach history hasn't helped confidence. The irony is that Authentik is genuinely more configurable than the SaaS alternatives — custom flows, policy engines, MFA, and social logins — all with no per-MAU pricing. If your app handles sensitive data, running your own auth means you control the session store, token lifetimes, and audit logs.

Best for: B2B SaaS teams, compliance-sensitive apps, developers who've hit Auth0's pricing wall.

Links: GitHub | Website

5) Forgejo — Git hosting that's actually yours

What it is: A community-maintained fork of Gitea that gives you a full GitHub-like experience — repos, issues, PRs, CI/CD hooks, and package registries — on your own infrastructure.

Why it matters in 2026: GitHub is owned by Microsoft. GitLab's self-hosted path got increasingly hobbled toward enterprise licensing. Forgejo is the community fork that said no thanks to both trajectories. It runs on a $5 VPS, mirrors to GitHub if you want redundancy, and doesn't phone home. For teams handling proprietary code or working in regulated industries, your Git host shouldn't be someone else's SaaS.

Best for: teams with IP concerns, regulated industries, developers who want GitHub UX without GitHub dependency.

Links: GitHub | Website

giphy.com

6) pompelmi — File scanning without sending files to the cloud

Why it matters in 2026: If you're self-hosting everything else, why are you sending uploaded files to a cloud AV API? That's a data exfiltration vector you're literally paying for. pompelmi gives you local file scanning in one function call — it wraps ClamAV without the usual C-binding pain or process management overhead. With LLM-generated code being used to create novel malware at scale, user upload scanning isn't optional anymore — and it shouldn't require trusting a third party with your files.

Best for: self-hosted file storage, Node.js backends with upload endpoints, teams running ClamAV who don't want to manage it directly.

Links: GitHub

7) Meilisearch — Search that doesn't bill per query

What it is: A fast, typo-tolerant, open-source search engine you self-host — think Algolia's UX without Algolia's pricing.

Why it matters in 2026: Algolia is still excellent. It's also $1/1000 operations, which adds up fast once you have any real traffic. Meilisearch delivers sub-50ms search out of the box, handles typos and faceted filtering natively, and ships as a single binary. The API is close enough to Algolia's that migration is low-friction. For any product where search is a core feature and you're already hosting your own data, this is a no-brainer.

Best for: product teams replacing Algolia, developers building search-heavy apps, e-commerce on self-hosted infrastructure.

Links: GitHub | Website

giphy.com

8) Windmill — Automate workflows without Zapier's pricing ceiling

What it is: A self-hosted workflow automation and internal tool builder — write scripts in Python, TypeScript, or Go, connect them into flows, trigger via webhook, cron, or API.

Why it matters in 2026: Zapier's task-based pricing model breaks at scale. n8n is solid but has a steep learning curve. Windmill is what you'd get if you rebuilt Zapier for engineers — scripts are first-class, version-controlled, and testable. Audit logs, RBAC, and secrets management are built in. Teams running internal ops, data pipelines, or API integrations are migrating here because the code is actually theirs.

Best for: engineering teams running internal tooling, data teams replacing Make/Zapier for complex flows, developers who want code-first automation.

Links: GitHub | Website

9) Netdata — Real-time monitoring without Datadog sticker shock

What it is: A high-resolution, real-time infrastructure monitoring agent that collects thousands of metrics with zero configuration and visualizes them in a live dashboard — fully self-hosted.

Why it matters in 2026: Datadog's pricing has become a running joke — teams routinely get hit with invoices they didn't budget for. Netdata installs in 60 seconds, collects at 1-second resolution by default, and the dashboard is genuinely better-looking than most paid alternatives. The Netdata Cloud tier is optional — you can run it entirely air-gapped. For teams that moved to self-hosted infra, this closes the observability gap without re-introducing a SaaS dependency.

Best for: self-hosted infrastructure, on-call teams who need high-resolution metrics, developers who tried Prometheus + Grafana and decided life was too short.

Links: GitHub | Website

giphy.com

Final thoughts

The cloud is still useful — but "we have to use the cloud" is almost never true anymore.

The tools above cover the full surface area of a production stack: inference, deployment, analytics, auth, version control, file security, search, automation, and observability. All open source. All self-hostable. All production-grade.

That's why the best infrastructure decisions being made right now are about:

Ownership over convenience
Privacy by architecture, not by policy
Cost predictability as a first-class engineering requirement
Vendor lock-in treated as a risk to be mitigated, not a feature
Local-first as the default, cloud as the deliberate exception

The irony is that the self-hosted stack is often faster, cheaper, and more reliable than the managed equivalent — once you get past the initial setup.

If I missed something obvious, drop it in the comments.

Which managed service are you most tempted to replace right now?

7 Mistakes Every Developer Makes in 2026 — And the Open-Source Fix for Each

Tommaso Bertocchi — Mon, 04 May 2026 10:59:30 +0000

Most "best practices" articles are useless.

They tell you to "write tests" and "use environment variables" without ever showing you the specific moment those warnings actually matter. You nod along and forget them by tomorrow.

This is the version with names, repos, and real consequences.

Every mistake below has a free, self-hostable open-source fix — no SaaS required.

These aren't theoretical. They're the kind of thing that causes a 3am incident, a silent data breach, or a "how did this even work" Slack thread that ends careers.

How I picked these

Not by StackOverflow survey popularity or Twitter discourse. I ranked by:

Cost of getting it wrong — does this mistake cause a data breach, an outage, or just mild annoyance?
How often developers skip it — not because they don't know better, but because the fix felt annoying to set up
Whether a drop-in open-source fix exists — something you can actually add today, not a six-month architecture project
Relevance to 2026 specifically — AI-generated code, LLM integrations, and supply chain attacks changed what "default safe" even means

TL;DR: The most dangerous developer mistakes in 2026 aren't about writing bad code — they're about skipping the invisible layers that make code trustworthy.

giphy.com

Infisical — Stop hardcoding secrets, you know who you are
pompelmi — Your file upload endpoint is a malware delivery service
SigNoz — You're flying blind the moment you ship
Atlas — Your database migrations are ticking time bombs
Scalar — Your API docs are a lie and your team knows it
Testcontainers — "Works on my machine" never fixed a production outage
Unkey — Your API is open for abuse right now

1) Infisical — Stop hardcoding secrets, you know who you are

What it is: A self-hosted secrets manager that replaces .env files, GitHub secrets, and the shame of finding your API key in a public repo two years later.

Why it matters in 2026: AI code assistants train on public repositories. If your key leaks into a commit, it's not just crawled by bots — it's potentially ingested into model training data. Secrets management is no longer a DevOps concern; it's an AI-era data hygiene issue. Infisical gives you a centralized vault with access control, audit logs, and SDK support for Node, Python, Go, and more — replacing the .env file that currently lives on 7 different machines with no rotation policy.

Best for: Solo devs tired of rotating leaked keys, teams onboarding new engineers, any project using more than 2 third-party APIs.

Links: GitHub | Website

giphy.com

2) pompelmi — Your file upload endpoint is a malware delivery service

Why it matters in 2026: Every app that accepts file uploads is one crafted .pdf away from distributing malware to other users. With AI-generated documents now trivially easy to weaponize, most upload handlers still do zero scanning — and they're one shared file away from becoming the distribution vector. pompelmi wraps ClamAV in a single function call, runs fully local (no files ever leave your server), and drops into any Node.js middleware stack in under 10 lines. It's the security layer most tutorials forget to mention.

Best for: Node.js APIs that accept file uploads, SaaS platforms with user-generated content, developers who need antivirus scanning without touching a cloud vendor's data pipeline.

Links: GitHub

3) SigNoz — You're flying blind the moment you ship

What it is: A full-stack observability platform (metrics, traces, logs) built on OpenTelemetry — a self-hosted alternative to Datadog and New Relic that doesn't send your data to a third party.

Why it matters in 2026: The average developer adds a console.log and calls it monitoring. Then their LLM-powered feature starts misbehaving at scale and they have no idea which requests are failing, why, or for whom. Observability is the difference between a 5-minute fix and a 3-hour war room. SigNoz uses OpenTelemetry natively — no vendor lock-in, no 6-figure Datadog bill, and your traces stay on your own infra.

Best for: Teams running microservices, developers building on top of LLM APIs who need to trace latency per model call, anyone who opened a surprise Datadog invoice.

Links: GitHub | Website

giphy.com

4) Atlas — Your database migrations are ticking time bombs

What it is: A schema management tool that treats your database schema like code — versioned, reviewed, and applied safely. Think terraform plan but for your Postgres or MySQL schema.

Why it matters in 2026: Half the startups I've seen have migrations that were run manually once and never committed. Someone adds a column in production, forgets to update the migration file, and three months later a new engineer runs migrate up and breaks staging. With AI assistants generating schema changes faster than ever, migration debt is compounding at a rate humans can't manually track. Atlas gives you a schema diff, a migration linter, and CI integration so schema changes go through the same review process as your code.

Best for: Postgres/MySQL/SQLite users, teams using ORMs that generate inconsistent migrations, any project where "just run this ALTER TABLE manually" has been said out loud.

Links: GitHub | Website

5) Scalar — Your API docs are a lie and your team knows it

What it is: A beautiful, interactive API reference generator that renders OpenAPI specs as live documentation with a built-in HTTP client, dark mode, and code generation.

Why it matters in 2026: Every team I've worked with has Swagger docs that are three sprints out of date. Developers end up Slack-messaging the engineer who wrote the endpoint instead of reading docs. When AI coding assistants generate code against your API, stale docs don't just waste time — they produce broken integrations at scale. Scalar auto-renders from your OpenAPI spec, runs as a single script tag or self-hosted service, and actually looks good enough that people open it voluntarily.

Best for: API-first teams, developer tools companies, anyone building something other developers will integrate against.

Links: GitHub | Website

Happy New Year Celebration GIF by Faith Holland - Find & Share on GIPHY

Discover & share this Happy New Year Celebration GIF by Faith Holland with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

6) Testcontainers — "Works on my machine" never fixed a production outage

What it is: A library (Node, Go, Java, Python, .NET, and more) that spins up real Docker containers for your tests — actual Postgres, Redis, Kafka, not mocks — and tears them down when the test finishes.

Why it matters in 2026: Mocking your database in tests is a lie you tell yourself. The mock passes, the query fails in production because your ORM generated slightly different SQL than you expected. AI assistants now write most test code, and they default to mocking everything — which means your test suite looks green while the actual behavior is untested. Testcontainers runs the real dependency for the duration of the test with zero local setup. No "but it worked in CI."

Best for: Backend engineers tired of flaky integration tests, teams where AI generates most test scaffolding, any project where unit tests keep missing bugs that only show up in staging.

Links: GitHub | Website

7) Unkey — Your API is open for abuse right now

What it is: An open-source API key management and rate limiting platform — create, revoke, and audit API keys with per-key rate limits and usage analytics, all via a single API call.

Why it matters in 2026: Most APIs either have no rate limiting or rely on a regex check on an Authorization header someone wrote at 2am. When AI agents start calling your API autonomously in tight loops, "no rate limit" becomes a self-inflicted DDoS from your own paying users. Unkey treats API keys as first-class objects — each key gets its own rate limit, expiry date, metadata, and audit trail. You can issue temporary keys for trials, revoke them in real time, and see exactly who is hammering your endpoint before it becomes a bill.

Best for: API developers who need per-customer rate limits, SaaS builders offering API access as a product feature, anyone whose API will be consumed by AI agents.

Links: GitHub | Website

giphy.com

Final thoughts

The mistakes that sink projects in 2026 aren't syntax errors or wrong algorithms — they're the invisible gaps in the trust layer: unscanned uploads, untracked secrets, unmonitored requests, untested integrations.

That's why the best open-source tooling right now is focused on:

Making the secure path the easy path, not the expert path
Replacing "just mock it" with real dependencies that actually behave like production
Treating secrets, schemas, and API keys as first-class versioned objects
Building observability in before you need it, not during the incident
Closing the gap between AI-generated code and production-worthy code

These tools aren't new ideas. They're the missing defaults that should have shipped with every framework from day one.

If I missed something obvious, drop it in the comments.

What mistake cost you the most hours to debug?

DEV Community: Tommaso Bertocchi

OSINT Prompts for ChatGPT and Claude: 5 Templates and a Repeatable Method

A note on ethics and scope, before anything else

The method: scope, collect, pivot, verify, document

The five prompts

1. Scoping

2. Email as a starting point

3. Username pivot across platforms

4. Domain and infrastructure

5. Verify and report

Make the prompts pull real data instead of guessing

Want the full set?

10 Best AI Agents for 2026

Table of Contents

1) OpenOSINT — Claude-native AI agent for OSINT and security research

2) Browser-Use — The browser automation layer the whole ecosystem builds on

3) OpenHands — The open-source answer to Devin

4) LangGraph — Production-grade stateful agent orchestration

5) CrewAI — Multi-agent teams that actually ship work

6) Letta — The agent framework that solved memory

7) smolagents — Hugging Face's code-first, zero-bloat agent framework

8) Dify — The LLM app platform with 80K+ stars and a serious workflow engine

9) SWE-agent — Princeton's coding agent with a clean Agent-Computer Interface

10) MetaGPT — Simulates an entire software company in your terminal

Final thoughts

10 Best Open-Source AI Agents for 2026

Table of Contents

1) OpenOSINT — Terminal-first AI agent for security research

2) Hermes Agent — Self-hosted agent that learns the longer it runs

3) OpenClaw — Your personal AI in every app you already use 🦞

4) OpenHands — The open-source answer to Devin

5) Browser-Use — Give AI agents a real browser and watch what happens

6) CrewAI — Multi-agent teams that actually ship work

7) AutoGPT — The pioneer that grew up into a real platform

8) MetaGPT — Simulates an entire software company in your terminal

9) SWE-agent — Princeton's coding agent with a clean Agent-Computer Interface

10) smolagents — Hugging Face's code-first, zero-bloat agent framework

Final thoughts

I built an MCP-native OSINT framework that lets AI agents investigate from your terminal

What is OpenOSINT?

Why MCP?

The 9 Tools

Architecture

Installation

Agentic OSINT in action

Optional: Breach + Phone Intel

What's next

Wrapping up

I Built an AI-Powered OSINT Agent That Investigates Targets Autonomously — From Your Terminal

What Is OpenOSINT?

The 11 Tools

The AI REPL

The Web Interface

MCP Server Mode

Architecture

Installation

A Note on Design

What's Next

Links

Why Every AI+Security Tool I Tried Was Lying to Me (And What I Built Instead)

The Wrong Way: Manual ReAct Loop

The Right Way: Native Tool Use API

The Architecture: OpenOSINT

The Tools

Why the Agent Approach Beats a Fixed Pipeline

Multi-Provider Support

What a Real Investigation Looks Like

Get Started

What I'd Do Differently

I built an AI agent that does OSINT investigations automatically

I built an AI agent that runs autonomous OSINT investigations from your terminal

What I built

The demo

The architecture

Why hallucination in tool results is structurally ruled out

9 tools

Installation

Using it

Interactive REPL

Direct CLI (no AI)