I Stopped Guessing What to Automate. So I Built an Open-Source Miner.
github.com/ghassan-ai-projects/automation-miner — Python, LangGraph, MCP, MIT licensed.
A few months ago, I asked an AI system to search six industries for automation opportunities.
It returned forty-two ideas in a day.
The number made a good headline. It did not make a reliable system.
The prototype could generate plausible opportunities, but the hard questions arrived immediately. Which claims came from evidence? Which scores were internally consistent? What happened when the input was a roadmap instead of an operational log? Where did rejected ideas go? Could another agent use the results without reading a pile of prose?
Those were not output-format problems. They were architecture problems.
So I rebuilt the experiment as Automation Miner: an open-source discovery engine that turns a domain description, one file, or a knowledge-base folder into a citable, scored portfolio of automation opportunities.
It does not decide what a company should build. It makes the discovery process inspectable enough for people to make that decision with better evidence.
The Discovery Gap Comes Before the Agent
Most AI projects begin too far downstream.
A team picks a chatbot, an agent framework, or a model. Then it searches for a workflow that justifies the choice. The result may be technically impressive and economically irrelevant.
The root cause is simple: solution design is easier to see than discovery quality. You can demo an agent. You cannot easily demo the opportunities you failed to consider, the weak assumptions you accepted, or the better project you never found.
Traditional process mining helps when an organization has clean event logs with stable case IDs and activities. Many automation questions start earlier, inside process documents, spreadsheets, emails, roadmaps, and partial descriptions. The evidence is useful, but it does not arrive as one perfect event stream.
Automation Miner is built for that earlier stage. Its output is not a deployment plan or an ROI guarantee. It is a structured backlog of hypotheses, each carrying its evidence, assumptions, risks, score rationale, and next validation questions.
The Pipeline Is a Funnel, Not One Prompt
The first version tried to do too much in one model call. The current system separates discovery into stages with explicit artifacts between them:
ingest → assess input → map domain
→ analyze five layers in parallel
→ plan a diverse portfolio
→ draft candidates in parallel
→ critique ⇄ refine
→ validate scores in code
→ apply constraints → publishThe five analysis layers look at the same evidence through different questions:
| Layer | What it looks for |
|---|---|
| Communication | Handoffs, status chasing, routing, escalation, and repeated coordination |
| Decision | Approvals, classifications, policy checks, exceptions, and judgment queues |
| Document | Extraction, reconciliation, form filling, report creation, and template work |
| Knowledge | Tribal knowledge, repeated questions, onboarding gaps, and missing procedures |
| Monitoring | Manual checks, thresholds, anomalies, SLA tracking, and delayed response loops |
The point is not to pretend these are the only dimensions of automation. Security, human oversight, reliability, cost, and organizational readiness cut across all five. The layers exist to reduce blind spots during candidate generation; the later stages test whether a candidate survives real constraints.
Evidence Has to Survive the Pipeline
Giving a model two hundred files does not create grounding. It creates a very large prompt.
Automation Miner turns every input into numbered chunks with a source and locator, such as [S12] claims.pdf p.4. Each stage receives only the slice relevant to its question. Selection uses deterministic BM25 before the model sees anything.
Large inputs are digested toward configurable budgets while preserving attribution. If the system still has to drop evidence, it drops whole attributed chunks instead of cutting sentences in half. Files that cannot be read are recorded with a reason rather than disappearing silently.
This is not a promise of zero hallucinations. A citation can exist and still be misinterpreted. Grounding makes a claim auditable; it does not make it true automatically.
That distinction changed the design. The critic checks unsupported claims and can force another refinement round. A hard grounding violation blocks publication. But the final brief still exposes assumptions and validation questions because discovery is uncertain by definition.
The LLM Proposes. Code Enforces.
ICE scoring looks objective because it ends in a number:
ICE = Impact × Confidence × Ease
each factor: 1–5
total range: 1–125But the inputs are judgments. Calling the whole score deterministic would hide the most important boundary in the system.
The model proposes Impact, Confidence, and Ease separately, with a rationale for each. Then code validates the proposal against the brief. High effort cannot also receive Ease 5. Low estimated impact cannot receive Impact 5. A candidate with no evidence cannot claim high confidence. Corrections can only lower a score, and every adjustment is recorded.
The multiplication, tiering, coherence rules, tie-breaking, and constraint policy are deterministic. The initial assessment is not.
That split gives the model room to interpret messy evidence without giving it final authority over the ranking rules.
Constraints Are Part of the Run Contract
A high-scoring opportunity can still be the wrong opportunity.
A low-budget team should not receive a portfolio dominated by expensive integrations. A compliance-heavy environment should not quietly promote an unresolved high-risk workflow. A three-person team cannot act on the same portfolio as a global platform organization.
Automation Miner passes constraints through planning, drafting, criticism, refinement, and scoring. Code applies the final policy after scoring. For example, low-budget runs require high Ease, compliance-heavy runs exclude unresolved high-risk items, and tight timelines favor the easiest candidates.
Excluded opportunities remain in the artifacts with their exclusion reason. Nothing vanishes just because it failed a filter. That matters because an idea rejected today may become viable after a policy, budget, or infrastructure change.
Operational Evidence and Strategy Evidence Are Not the Same
One subtle failure in the prototype was treating every input as a description of current reality.
A roadmap says what a team wants to do. A market report says what might be happening. Neither proves that a current workflow has a specific volume, duration, or error rate.
The Miner now has two modes. Operational mode expects evidence about owners, systems, handoffs, volumes, errors, and controls. Strategy mode produces hypotheses with explicit assumptions and validation questions. An evidence preflight can choose the mode automatically, or the operator can set it.
This sounds like a small classification step. It prevents a large category of false confidence: turning a proposal into a measured process simply because both appeared in the same document.
The Output Is Built for Humans and Agents
Every run writes its intermediate state as JSON. The run manifest, context index, domain map, five layer analyses, portfolio plan, every draft and critique version, validated scores, ranked portfolio, exclusions, token usage, and final report all remain available.
The human-facing output is a set of self-contained AM-XXX briefs. The agent-facing output is a compact summary and registry. The MCP server exposes tools to mine a domain, inspect runs, query the registry, retrieve one opportunity, and rebuild the index. The CLI provides the same core workflow.
There is no UI. That is deliberate. The Miner is a discovery component, not another dashboard that becomes the place where findings go to die.
A basic run looks like this:
git clone https://github.com/ghassan-ai-projects/automation-miner.git
cd automation-miner
uv sync
# Zero-cost end-to-end run with the deterministic mock model
uv run automation-miner mine "German healthcare back office" --dry-run
# Mine a real knowledge base with binding constraints
uv run automation-miner mine --kb ./process-evidence/ \
--mode operational \
--constraints "budget:low, compliance:heavy"What It Does Not Solve
Automation Miner can improve discovery. It cannot repair missing evidence, political resistance, unclear ownership, or a process nobody understands.
Its ranking is a decision aid, not a business case. Before building anything, a team still has to validate volumes, failure costs, integration access, security boundaries, human oversight, adoption, and who owns the automation after launch.
The current release is 0.1.0 and alpha. Artifact schemas may change. Failed runs leave durable diagnostic artifacts, but the public resume command and checkpoint compatibility policy are not implemented yet. Scanned PDFs need OCR before ingestion. Model quality and evidence quality still shape the result.
I am stating those limits because discovery tools are especially easy to oversell. A polished opportunity brief can create more confidence than the underlying evidence deserves. The architecture should make that gap visible, not decorate it.
Why I Open-Sourced It
The interesting part of Automation Miner is not a private list of ideas. It is the machinery that makes discovery inspectable: reader plugins, evidence budgets, structured schemas, critic loops, scoring boundaries, constraint policy, durable artifacts, and MCP tools.
Those mechanisms get better when engineers can challenge them.
The project is MIT licensed and ships with an offline mock model, tests, extension points for document readers, provider routing, contribution guidance, a security policy, and the same commands used in CI.
I started with a system that could produce forty-two plausible ideas.
I ended with a system designed to show why any one of them deserves another hour of investigation.
Discovery should not be a whiteboard contest. It should be an evidence trail you can inspect, challenge, and improve.
That is what Automation Miner is for.
Read more technical writing and case-study notes from the archive.
Read More Articles