How I Got Here

---

My career did not follow a straight line. Looking back, that may be the reason I ended up here.

I went to school for accounting and finance. While attending school, I worked for a developer that built and operated its own projects, including midscale hotels, condominiums, and apartments. That gave me an early view of something I would encounter repeatedly throughout my career: accounting does not exist separately from operations. The numbers are the result of decisions being made somewhere else.

The recession of the late 1980s and early 1990s made finding work difficult, and my career moved through several different environments before I eventually joined a real estate property management company as Controller, with responsibility for information technology as well.

Computers had already become an important part of how I worked. I understood much of the technology, but I was told that if I was going to be responsible for Microsoft systems, I needed to learn what someone jokingly described to me as “the Bill Gates way.” So I went back to school and became a Microsoft Certified Systems Engineer (MCSE).

I stayed long enough to help the company through the Y2K transition and then decided I needed a break.

It didn't last very long.

“These People Mow Lawns”

A headhunter—that is what we called them at the time—contacted me about becoming Controller for a landscape architecture and land planning firm.

My first thought was:

      “These people mow lawns.”

I would spend the next 26 years learning just how wrong that assumption was.

The firm needed more than a Controller. Project managers needed better ways to develop project budgets, understand profitability, and determine what should actually be included in a proposal.

I started asking questions and recommending changes.

The response I sometimes received was fair:

      “You don't know our industry. You don't know what's involved in a project.”

They were right.

So I went back to school.

I studied landscape design, irrigation, and AutoCAD because I did not want to understand projects only through their accounting records. I wanted to understand what the people producing the work were actually doing.

While I was in school, I began developing increasingly detailed project budgeting and proposal templates. They connected labor, project phases, consultants, expenses, overhead, and profitability so a project manager could see what it would actually take to perform the work being proposed. Eventually, that financial analysis became part of the proposal process itself.

Once I understood the technical side of the work, my responsibilities continued expanding. I became involved in QA/QC, proposals, marketing, contracts, consultants, administrative operations, project management, agencies, and the relationships between all of them.

What started as an accounting position became an education in how an entire project-based organization works.

Taking Responsibility for the Outcome

In 2011, the firm's principal wanted to retire.

Taking over a landscape architecture and land planning company was certainly not something I had gone to school to do. Other senior staff did not want the responsibility, and there was no guarantee about what would happen if someone took it on.

So I did.

You should have seen their faces.

When I assumed responsibility for the company in 2011, we were providing landscape architecture services as part of the consultant team for a $500 million hospital project. 

Working within a multidisciplinary project of that scale reinforced how much successful project delivery depends on coordination—not only within the design work, but across contracts, staffing, schedules, information, and the many disciplines involved.

From that point forward, understanding a project was no longer enough. I was responsible for its outcome.

I became involved in virtually every stage: developing proposals, negotiating and winning contracts and multiyear agreements, assembling project teams, coordinating consultants, working with agencies and communities, visiting sites, producing drawings and specifications, integrating consultant work, managing financial performance, and dealing with the problems that inevitably develop over the life of a project.

That experience changed the way I think about information.

A project does not exist in one drawing, spreadsheet, contract, email, specification, meeting, or database. Different people see different pieces of it. Decisions made in one place can affect something somewhere else months or even years later.

The difficult part is often not creating information.

It is maintaining the connections between it.

The Beginning of eco619

One of the more complex projects I became involved with included a long-term water and environmental study associated with approximately 4,000 homes in Northern California.

The study ultimately continued for approximately nine years. About six years into that work, I was dealing with calculations and environmental variables that were becoming increasingly interconnected. Software existed for individual portions of the problem, but I was trying to understand relationships across more of the environment than those individual tools represented.

I began building my own software to work with the problem.

I eventually showed what I had developed to a friend with extensive technology and systems-design experience and asked a simple question:

      “Is there something here?”

He thought there was.

That led to the original eco619.

I funded the effort, assembled the teams, developed software myself, and used his experience primarily to help with system design. We began developing software ecosystems around facilities-management applications and later worked on projects involving solar applications and agricultural growers.

eco619 was established as a California business and remained under my ownership. In 2020, circumstances in my personal life made continuing to operate two companies impractical, and I had to choose where to put my time. I wound down active operations at eco619.

I didn't know then that I would eventually have another use for it.

Thirty-Five Years of Information

When I assumed responsibility for the landscape architecture and land planning firm, I was also assuming significant personal and financial risk.

As part of that transition, I made sure that ownership of the company's historical files was transferred to me. My thinking at the time was fairly simple: if I was putting my financial future on the line, I needed an asset.

The files were that asset.

Who knew?

When the firm eventually wound down operations after approximately 35 years, those records represented decades of organizational history. I personally knew the outcomes and context surrounding much of the most recent 26 years.

The collection also crossed generations of technology.

There were contemporary files, but also older formats and information structures that are disappearing from modern organizations—different generations of email, documents, spreadsheets, drawings, PDFs, images, project records, accounting information, and other artifacts created by different people using different software over many years.

At the time those files were created, nobody was thinking about artificial intelligence trying to understand them decades later.

Neither was I.

Then AI Arrived

Like many people, I initially began using generative AI as a tool. In 2022, I used it to help with a proposal.

But by 2024, my questions had changed.

I didn't just want to know what AI could write for me. I wanted to understand what it actually knew, what information it was using to reach an answer, what it could miss, and how much responsibility I could reasonably give it.

So once again, I went back to school.

I studied artificial intelligence, software engineering, prompting, Python, and software architecture—not because my goal was to become a traditional software developer, but because if I was going to architect and build an AI system, I wanted to understand what was happening underneath it.

At some point I realized that the path I had taken throughout my career had placed an unusual problem directly in front of me.

I had decades of real organizational information.

I understood much of its history.

I knew the outcomes of many of the projects.

I understood why many of the documents existed and how different disciplines used them.

I had access to much of the software needed to interpret the original artifacts.

And I now had AI.

What a new challenge.

Building Continuous Intelligence

That challenge became the Continuous Intelligence Platform.

The objective is not to build an AI that simply answers a question from whatever information happens to be in its immediate context. I am building a system intended to preserve organizational information and its relationships over time.

I sometimes describe the idea less technically as giving AI the memory of an elephant.

If something happened two years ago, the system should not lose it merely because the current conversation has moved on. New information should be capable of reconnecting with old information when that earlier information becomes relevant again.

Achieving that requires considerably more than connecting an AI model to a folder of documents.

The platform uses orchestrators, agents, components, workers, managers, readers, processors, routers, queues, claims, handoffs, persistence, lineage, and verification processes. Responsibilities are intentionally separated so individual components have specific jobs and their behavior can be tested independently.

During development, core components were built for standalone execution so they could be tested, corrected, retested, and validated before being integrated into the larger autonomous platform.

The architecture also does not assume that something is true simply because an AI model produced it. Verification, source traceability, provenance, claims, lineage, and multi-pass processing are used to preserve the relationship between what the system concludes and the source information from which that understanding was developed.

The platform is also designed to remain provider-agnostic. The organizational knowledge belongs to the system using it, rather than depending upon the memory of a particular AI provider. AI providers and models can therefore change as the technology changes without requiring the accumulated organizational knowledge to begin again.

The Continuous Intelligence Platform has now progressed through component validation and multiple integrated platform tests and is undergoing baseline testing and refinement. The remaining work also includes development of the user-facing interface through which people will ultimately interact with the system.

Looking Back

None of this was a career plan.

Accounting led me into business operations. Business operations led me further into technology. Project finance led me into design and land development. Running projects led me deeper into contracts, consultants, agencies, communities, information, and responsibility for outcomes. Environmental work led me toward interconnected data and software.

And decades of accumulated project information eventually led me to artificial intelligence.

I didn't set out thirty years ago to build an AI system. The technology didn't exist.

What I eventually realized was that much of what I had spent my career learning—how information moves through organizations, how different disciplines see the same project differently, how decisions accumulate over time, and how easily context can disappear—had become the problem I wanted to solve.

That is what eco619 is today.