About

Hi. I’m Anthony.

I try to make scientific computers stop waiting around for their data. That is the short version. The longer version is about turning research questions into systems, turning prototypes into software, and creating enough structure around a good idea that other people can own it.

My path here was not linear. Before computer science, I worked in environments where reliability was not an abstract quality. When systems failed, people noticed. I still carry the lesson: reliability isn’t a feature. It’s the floor.

Chicago became home when I came to Illinois Tech for a Ph.D. The question I settled into sounded narrow: how do we get data to processors without wasting the machine around them? It kept opening into larger questions about storage, metadata, context, tools, and the people using them.

I am most interested in the moment when an idea has to negotiate with the world: dependencies, users, collaborators, evidence, failure, and change.

What I build

Several threads keep reconnecting:

Agents need the right data, metadata, tools, and state at the right moment.
Storage hierarchies should be steerable by applications rather than invisible machinery.
I/O should carry intent instead of becoming an anonymous byte stream.
Benchmarks are tools for arguing honestly about behavior.
Research becomes more useful when someone can run, inspect, and extend it.

The current expression of those threads is CLIO, the context layer my team and I are building through IOWarp. I lead CLIO as its overall PI and architect; the team owns its components. The piece I write myself is Clio Coder, a terminal coding agent for scientific software that runs against a model on your own GPU and seals a receipt for everything it does. It is the work I am proudest of right now.

The earlier systems (LABIOS, Hermes, ChronoLog, IRIS, and others) are not a sequence of disconnected projects. They are a lineage of questions, architectural bets, and software lessons, and the project atlas shows how the whole graph fits together, private prototypes included.

How I work

Build beyond the paper.

A result becomes more useful when somebody can install it, test it, disagree with it, or carry it into a different system.

Make the evidence legible.

Code, releases, benchmarks, papers, talks, and limitations should tell one connected story.

Give people real ownership.

Mentoring works when a person owns consequential decisions, not only the tasks left after the decisions are made.

Name the boundary.

Say what works, what is experimental, what is planned, and what remains uncertain.

Building with people

Most of the work I am proudest of does not have my name on the first line of the byline. Research is collective, and software makes that obvious: someone frames the problem, someone finds the failure, someone rebuilds the interface, someone writes the test that finally tells the truth.

My aim as a mentor is independent judgment. I want people to grow past my advice, disagree with an architecture for reasons I missed, and have the evidence and communication skill to carry a better idea forward.

Building GRC is my evolving account of the environment around that work. The Gnosis Research Center remains the institutional home and complete catalog.

Current roles

Titles are context, not the headline. The work is about architecting systems, shipping tools, building teams, teaching, and creating room for other people to do ambitious things.

Connect

Write if you are building around data systems, scientific AI, research software, or agent infrastructure; if a workload is slower or stranger than it should be; or if something here gives you a useful disagreement.

The direct public channel is [email protected]. You can also find the formal record in the Archive and CV.

GitHub ↗LinkedIn ↗Google Scholar ↗ORCID ↗DBLP ↗Gnosis Research Center ↗