Cogen - Venture Twin

Inspiration

Starting a business always involves uncertainty, but I kept coming back to one question: why do founders still commit real money before properly modelling what could go wrong?

We now have enough intelligence, data, and computational power to test many assumptions before capital is committed. Yet most business decisions are still made through spreadsheets, scattered research, intuition, and optimism. By the time reality disproves an assumption, the founder may already have signed a lease, hired employees, bought inventory, or spent a significant amount of capital.

I also experienced another problem that is especially common when building without a co-founder. When you are alone, there is nobody consistently challenging your assumptions. It becomes very easy to become attached to an idea, ignore uncomfortable evidence, underestimate risks, or simply fail to notice an important blindspot.

That became the idea behind Cogen: a persistent venture twin that behaves less like an assistant answering questions and more like a partner whose job is to understand the business, challenge it, and help determine what must be true before the founder commits.

What Cogen Does

A founder starts by describing a venture, available capital, financial targets, risk tolerance, and other important constraints.

Cogen turns that information into a structured model of the business. It identifies assumptions, gathers and evaluates evidence, runs specialist analysis across different parts of the venture, and stress-tests the economics using Monte Carlo simulation.

Instead of simply generating a business plan, Cogen produces explicit decisions such as conditional, reject, or approve, together with the reasons behind them.

More importantly, it identifies what the founder still does not know.

For example, a supermarket may appear profitable under the founder's estimates, but Cogen might discover that the entire investment depends on an unverified assumption about daily customer transactions. Rather than hiding that uncertainty inside a financial forecast, Cogen exposes it as a critical blindspot that should be resolved before capital is committed.

The venture remains persistent, so new evidence, changed assumptions, experiments, and decisions update the same underlying model instead of starting another disconnected AI conversation.

How I Built It

Cogen's backend is built with FastAPI and deployed using Google Cloud Run.

The founder-facing agent uses Google ADK, while Gemini 3.7 Flash performs the model-driven reasoning used throughout the venture analysis. Specialist passes examine different areas of the business while working from shared venture state.

The system stores persistent venture information in PostgreSQL through Neon, including assumptions, evidence, decisions, events, and changes over time.

A deterministic underwriting layer then takes the structured information produced by the agent system and runs financial modelling, including thousands of Monte Carlo simulations. This separation was intentional: language models are useful for interpreting uncertain information, but important financial calculations should not depend entirely on unconstrained language generation.

The result is an agentic system that combines reasoning with structured state, deterministic computation, and explicit execution gates.

What I Learned

One of the biggest lessons from building Cogen was that an intelligent agent becomes much more useful when it has something durable to reason about.

A normal conversation disappears into a sequence of messages. A venture does not work that way. Decisions made today depend on evidence gathered yesterday, assumptions may later become invalid, and new information can completely change whether an investment still makes sense.

I therefore learned to treat the venture itself as the central object, while the agent becomes a way of inspecting, challenging, and modifying that object.

I also learned that uncertainty should not always be eliminated. Sometimes the correct output is simply: we do not know this yet, and committing money before finding out would be dangerous.

That became an important principle behind Cogen.

Challenges

The hardest challenge was moving beyond a chatbot that merely sounded intelligent.

Cogen needed to actually maintain state, coordinate different forms of analysis, distinguish evidence from assumptions, perform real calculations, and remain useful as the venture changed.

Integrating model reasoning with deterministic financial analysis also required careful boundaries. I did not want a confident paragraph from an AI model to become the equivalent of verified business evidence.

Deployment introduced another challenge. The production system successfully deployed and ran on Cloud Run, while the public Cloud Run endpoint developed a routing issue close to the submission deadline. This forced me to separate application correctness from infrastructure accessibility and verify the production container, Gemini execution, database persistence, underwriting flow, and ADK agent independently.

Ultimately, Cogen became an attempt to answer a simple question:

Before a founder risks real capital, how much uncertainty can we remove—and which remaining uncertainties are important enough to stop them from proceeding?

Built With

• 3.7
• actions
• adk
• api
• artifact
• cloud
• docker
• fastapi
• federation
• flash
• gemini
• github
• google
• identity
• neon
• postgresql
• python
• registry
• run
• sqlalchemy
• workload