Understand what someone is actually trying to accomplish.
TALK TO ME ↗TALK TO ME ↗THE CREATOR IN THE LAB / JESSICA CHELMIS
CREATOR / FOUNDER, EVO
Some people specialize
in an answer.
I tend to become interested
in the problem.
“I help growing businesses redesign how work gets done — improving workflows, systems, handoffs, visibility, and automation so they can scale with less friction and less manual overhead.”
01
WHY
I believe companies should learn, remember, and improve—instead of repeatedly paying for avoidable friction and failure.
02
HOW
I diagnose the system underneath the symptom. Then I redesign the workflows, information flow, decision boundaries, ownership, controls, institutional memory, and automation surrounding it.
03
WHAT
I design operating architecture, improve systems and processes, implement AI and automation, and resolve the operational bottlenecks that prevent growing companies from scaling effectively.
What I Actually Do
I work on the operating structure beneath growth: how work moves, where information lives, how decisions are made, and which capabilities belong in the system.
01SYSTEMS AND PROCESS DESIGN02OPERATIONAL ARCHITECTURE03GROWTH BOTTLENECKS04INTEGRATION05AUTOMATION06AI IMPLEMENTATION / WHERE APPROPRIATE
This is how I got here.
I didn’t start with a theory about operating architecture.
I got there by spending years inside very different organizations and eventually realizing that, beneath the surface, many of them were struggling with the same kinds of structural problems.
Over time, breadth of experience became a way of seeing. Pattern recognition became an earned ability. And alongside it developed something more specific: Comparative systems recognition — seeing that two companies can look nothing alike on the surface while failing for structurally similar reasons underneath.
That became Constraint Interrogation: refusing to accept the apparent constraint until I understood what was actually governing the outcome. The goal became to make the system stronger, not merely make the current problem disappear.
Read the full operator-origin story →Follow the work from observation to architecture.
Evidence belongs in the artifacts, cases and research—not in unsupported claims.
I AM THE HUMAN.
EVO can extend me with research systems, AI models, agents, software, algorithms, data, optimization, automation and specialist expertise. I remain the human relationship and judgment layer.
“The machines expand what I can do. They don’t decide what matters.”
Uncover assumptions, contradictions and missing information.
Move between customers, executives, operators, specialists and technical systems without losing the problem.
Bring people, information, technology, systems and specialized intelligence together without losing sight of the original problem.
Turn an ambiguous need into something concrete enough to build.
Coordinate people with different knowledge, incentives and responsibilities.
Respond when reality differs from the plan.
Recognize when context, relationships, economics or consequences require human judgment.
Remain accountable to whether the result is useful to the person or organization it was created for.
Direct project work with people and organizations—integrating business, creative and digital needs into work that could be designed and delivered.
Direct work with customers, companies, vendors, trades and projects—integrating requirements, budgets, expectations, physical reality and execution.
The technology changed. The human work didn’t.
Access to intelligence does not automatically diagnose an organizational problem, reconcile conflicting human realities, determine what matters economically or remain accountable for whether an intervention is useful. My role combines human inquiry, accumulated operating context and increasingly powerful technical leverage.
Technology expanded what I can reach. It didn’t replace the human work required to understand what is worth reaching for.Different environments trained the same instinct.
Design, customers, operations, company ownership and changing technology each exposed a different part of the problem. The path is unconventional, but it is not random.
The instinct didn’t.
Begin with the contact surface: what hurt, what the obvious path could not solve, what reality refused to confirm, and what question survived.
CASE / 01PARTIALLY SOLVED
A company became too dependent on the owner.
- BLOCKER
- The owner held judgment, exceptions and cross-functional state that the systems did not.
- LOSS
- Capacity, scalability and institutional resilience.
- QUESTION
- Which interventions require founder judgment—and which exist because memory, state or routing is missing?
- INVENTIVE MOVE
- Separate human authority from human middleware; inspect the architecture before adding another person.
- WHAT WAS BUILT / TESTED
- Operating processes and systems were developed inside a real company. That work produced a larger architecture question: which responsibilities truly require the founder?
- WHAT BROKE
- Formalizing too early can encode an immature process. The founder cannot simply be removed from consequential judgment.
REALIZATION
Founder dependence can be a leadership fact and an architecture signal at the same time.
WHAT THIS UNLOCKED NEXTBuild Architecture, Not Headcount?CASE / 02SUPPORTED / FAILED PREMISE
Working software solved the technical problem but missed the commercial and human problem.
- BLOCKER
- The build proved function before the most consequential uncertainty had been tested.
- LOSS
- Time, attention and capital behind the wrong proof.
- QUESTION
- What must be true for this to matter—not merely work?
- INVENTIVE MOVE
- Move the prototype toward the riskiest uncertainty, including desire and behavior.
- WHAT WAS BUILT / TESTED
- A functional system was built and exposed to reality.
- WHAT BROKE
- Technical success did not produce the expected commercial meaning.
REALIZATION
Working software is evidence of function, not evidence of value.
WHAT THIS UNLOCKED NEXTA stricter research → prototype → measurement discipline.CASE / 03TESTING
Valuable intelligence accumulated inside AI conversations without becoming durable organizational memory.
- BLOCKER
- Conversation provided interpretation but not authoritative state, provenance or reassessment.
- LOSS
- Knowledge, consistency, repeated decisions and owner dependence.
- QUESTION
- What deserves promotion from fluid conversation into governed memory?
- INVENTIVE MOVE
- Separate interface from memory and separate suggestion from authority.
- WHAT WAS BUILT / TESTED
- Memory experiments and public research into storage, learning, provenance and supersession.
- WHAT BROKE
- More captured output created more material without automatically creating more usable memory.
REALIZATION
Conversation is not memory. Storage is not learning.
WHAT THIS UNLOCKED NEXTCompanies That Learn and the Architecture of Intelligence.TECHNOLOGY / CAPABILITYTHEN THE TOOLS CHANGED.
The available design space kept expanding.
Each milestone is credited to its creator. The chronology follows what became practical for builders and how Jessica’s operating questions changed.
2022COMPOSABLE FOUNDATIONS
Cloud and serverless compute, storage and databases kept reducing the infrastructure required to ship applications. API-first SaaS, integration tools, low-code automation and conventional software were already increasingly composable; coding assistance entered the everyday development environment.
WHAT THIS CHANGED FOR BUILDERSA small builder could assemble hosted capabilities instead of owning every layer—and move from operating question to deployed tool with less infrastructure and less code.
Jessica was building and running real operations. The problems arrived first; the available components were becoming easier to combine.
2023MODELS + TOOLS DIVERSIFY
Commercial foundation models gained structured tool calling while openly available model weights expanded access outside a single provider. Language capability could now be connected to APIs, software and data rather than remaining only a conversational surface.
WHAT THIS CHANGED FOR BUILDERSNatural-language interfaces, extraction, classification, retrieval and tool-connected prototypes became practical for more builders. Model choice widened; architecture still had to supply rules, state and authority.
The cost of pursuing certain questions began to fall. Research, design and prototype work that once died early could survive long enough to meet reality.
2024MULTIMODAL + CONNECTED
Long-context multimodal models could work across text, documents, images, audio and video. Computer-use experiments extended capability into existing interfaces. MCP proposed an open connection layer between assistants and external systems.
WHAT THIS CHANGED FOR BUILDERSMore of the real operating environment could become input. Builders could investigate document-heavy, visual, voice and legacy-interface workflows without first rebuilding every system.
GOOGLE / GEMINI 1.5 ↗ANTHROPIC / COMPUTER USE ↗ANTHROPIC / MCP ↗
The question moved from what a model could answer toward what a composed system could participate in. Conversation was not architecture, and output was not organizational truth.
2025SYSTEMS BECOME AGENTIC
Agent frameworks made tool loops, approvals and provider switching more explicit. Hosted runtimes supported persistent work, while open protocols addressed model-to-tool and agent-to-agent interoperability.
WHAT THIS CHANGED FOR BUILDERSSmall teams could compose models with APIs, software, data, queues, human approval and deployment infrastructure. The hard problem shifted from producing an answer toward governing a working system.
The working question became compositional: what intelligence does this problem require, and how should judgment, rules, models, software, data and specialists relate?
2026ORCHESTRATION IS THE DESIGN PROBLEM
Coding agents, secure sandboxes, background workflows, provider gateways and protocol support continued lowering the cost of building and operating connected systems. Capability became broader, longer-running and easier to recombine.
WHAT THIS CHANGED FOR BUILDERSThe feasible design space expanded again—but so did the importance of deterministic boundaries, data integrity, optimization, memory, observability, security and human authority.
The inquiry became larger than one operating company. EVO became the laboratory for investigating which capabilities belong around a problem—and whether the resulting system actually works.
The problem determines the orchestra.
Architecture means how the work fits together: who decides, who knows, where information lives, what software and people do, what gets remembered and measured, and where time, money or capacity is lost.
HUMAN / INQUIRY LEAD
Jessica Chelmis
Jessica holds the relationship, context, curiosity, translation, judgment and responsibility. The other capabilities are assembled around the problem.
RELATIONSHIPCONTEXTCURIOSITYTRANSLATIONJUDGMENTRESPONSIBILITY
AVAILABLE CAPABILITIESILLUSTRATIVE SELECTION / THE ANSWER IS NOT PRESELECTED
01 / START HERETHE PROBLEM
What must change—and what does this situation actually require?
02 / SELECT ONLY WHAT BELONGSHUMAN INTELLIGENCE MACHINE / ANALYTICAL ENGINEERED CAPABILITY FOUNDATION
OPERATORDOMAIN EXPERTSPECIALIST EXPERTISE
LLMSTATISTICAL MODELOPTIMIZATIONALGORITHM
DETERMINISTIC SOFTWARESOFTWARE ENGINEERINGAGENT
DATARESEARCH
03 / INTEGRATE THE SELECTION
SYSTEM
DOMAIN EXPERTDATADETERMINISTIC SOFTWARELLM
WORKINGSYSTEM
THE PROBLEM DETERMINES THE ORCHESTRA.INTEGRATION MAKES IT A SYSTEM.
YOU DO NOT NEED TO KNOW WHICH OF THESE YOU NEED. THAT IS PART OF THE INVESTIGATION.
Agentic AI generally means software that can do more than answer a question. Within defined boundaries, it can use tools, follow processes, check conditions, create or update information, and escalate to a human when required. It does not remove the need for human judgment. READ THE RESEARCH →
Corrigibility is part of the work.
“I thought working software meant the problem was solved.”
Reality separated function from human and commercial validity.“I thought productive AI conversations could carry important organizational knowledge.”
Reality separated conversation from governed memory.“I thought more intelligence was necessarily better.”
Orchestration complexity showed that more output can make a system less legible.“I thought an attractive architecture principle might be novel.”
Prior-art research revealed its ancestry and made the actual contribution more precise.Contact with reality changes the creator.
Each note records what was assumed, what happened, what was lost and what changed.
CREATOR / BUILDERTHEN I LIKE MAKING THINGS.
I don’t have a product to sell you.
EVO does not begin with a platform, prebuilt agent, automation package, dashboard or software suite and then search for a reason to deploy it.
The answer may use AI, conventional software, automation, data, process redesign, human judgment, specialist expertise, an existing commercial product—or nothing new at all.
EVO can reuse methods, patterns, components and failure knowledge without forcing the next organization into the previous solution.
THE PRODUCT SHOULD NOT PRECEDE THE PROBLEM.The path matters only because it shaped how I approach problems.
If something inside one division is expensive, stubborn, strangely manual, difficult to scale, cross-functional, newly possible because technology changed—or resistant to conventional solutions—I’d be interested in understanding it with you.
BEGIN WITH ONE QUESTION, IDEA OR DIFFICULT SITUATION INSIDE ONE DIVISION.START AS SMALL AS THE UNCERTAINTY ALLOWS. EXPAND ONLY WHEN REALITY EARNS IT.RESEARCH / UNDERSTAND ITARCHITECTURE / DESIGN ITPROTOTYPE / PROVE ITIMPLEMENTATION / MAKE IT OPERATIONALMEASUREMENT / FIND OUT WHETHER THE HYPOTHESIS WAS RIGHT
Literal record.
Selected roles and dates.
EVO
Creator & Founder
AUGUST 2026—PRESENTAlta Renovations
Owner / Operations & Systems Manager
JANUARY 2022—PRESENTDesign Eleven Eleven
Creative Director / Digital Operations / Client Support
2010—JANUARY 2024The part of this work I love most isn't technology for its own sake, or changing things simply because we can. It's reaching the point where we understand something well enough to see a genuinely better possibility.
And if that possibility requires something that doesn't exist yet, I like making things too.
What matters is what happens afterward. Did it create enough value to justify the disruption? Did we preserve the things that were already good?
You don't need to come to me with any of that figured out. You don't need a diagnosis, technical vocabulary, or even certainty that there's a problem.
Just tell me what you've been thinking about. I'd genuinely like to hear it.
Jessica