Context
SingularityNET is one of the longest-running labs working on AGI from a non-deep-learning angle. The core idea isn't "scale a transformer until it generalizes"; it's a graph-based knowledge representation (the AtomSpace), a reasoning layer on top, and economic attention mechanisms that decide what the system thinks about next.
I worked across two areas:
- Pattern Miner — finding meaningful sub-graphs in the AtomSpace
- ECAN (Economic Attention Allocation) — how the system distributes a limited "attention" resource across concepts over time
This case study explains what those mean in plain terms and what I actually built.
What is the Pattern Miner
The AtomSpace stores knowledge as a hypergraph: nodes are concepts, links are relationships, both can be nested. A "pattern" is a small sub-graph that appears unusually often. Find enough of them and you have something like the system's vocabulary of recurring ideas.
The hard parts are:
- The graph is huge and changes constantly
- Naive enumeration is exponential
- "Unusually often" needs a probability model that doesn't itself blow up
My contributions were in the candidate generation and scoring layers — making the miner explore the right neighborhood instead of the entire graph, and rejecting patterns that were statistically uninteresting before paying their evaluation cost.
What is ECAN
ECAN treats attention as a budget. Each atom in the graph has two values:
- STI (Short-Term Importance) — does the system care about this now?
- LTI (Long-Term Importance) — has this been useful historically?
A small "central bank" redistributes these over time based on how atoms are being used. Concepts that are forming useful patterns get more attention; stale ones decay.
I worked on diffusion (how STI moves between connected atoms) and forgetting (the boring but critical other half — bounded memory is non-negotiable in a long-running system).
What I actually shipped
Pattern Miner
- Tightened the candidate filter so the miner skips obviously non-promising sub-graphs early
- Added statistical pre-screening to avoid running expensive frequency counts on patterns that couldn't pass the threshold
- Wrote tests against curated knowledge fragments so future changes have a measurable signal
ECAN
- Profiled and reduced the per-cycle cost of attention diffusion
- Added convergence checks so the simulation could be stopped meaningfully instead of running forever
- Documented the actual parameter ranges that produced stable systems (the prior docs trailed reality)
Research engineering vs research
I am not claiming to be a theorist. My contribution was making the existing ideas runnable, profilable, and testable — the unglamorous half of any research codebase.
How this is relevant outside AGI work
Pattern mining and attention allocation are not weird academic toys. The same shapes show up in:
- Recommendation systems (which items deserve attention this session?)
- Anomaly detection (which sub-graphs occur unusually often?)
- Agent memory (what should an LLM agent keep in its working context?)
A lot of the work I do today on LLM agents — RAG selection, context budgets, scoring — uses the same instincts.
What I would do differently
- Add a clear benchmarking story earlier: research code without numbers becomes uncomparable across branches very quickly
- Spend more time wrapping the C++ core with a friendly Python surface for experimentation — the ergonomic gap costs real research hours
Stack at a glance
- Core: OpenCog / Hyperon (C++ + Scheme + Python bindings)
- ML experimentation: Python, PyTorch
- Profiling: Linux perf, cProfile, custom instrumentation
- Ops: Linux, git-based research workflow
Why this matters on a portfolio
Recruiters look at this and see two things: ability to operate inside a complex research codebase, and willingness to ship the boring infrastructure that makes other people's ideas testable. Both translate directly to senior engineering roles.