I’ve been working with semantic web technologies since 2012. RDF, OWL, SPARQL, Protege, Jena, triplestores -- these have been part of my toolkit for over a decade. I’ve built ontologies for research projects, designed knowledge graphs for NLP pipelines, and written more SPARQL than I’d care to admit.

And throughout all of it, one frustration has remained constant: the gap between what knowledge graphs can do and what people are willing to put up with to use them.

The technology is sound. The W3C stack is well-designed. Ontological reasoning is genuinely powerful. But the barrier to entry has always been too high. You need to understand RDF serialization, SPARQL syntax, OWL semantics, URI design, and named graph management before you can do anything useful. For most teams, the learning curve kills adoption before the value becomes visible.

LLMs have finally given us the tools to close that gap. So I built KeplAI -- an open-source platform that puts an AI layer on top of the standards-based semantic web stack, making knowledge graphs accessible without sacrificing the rigor that makes them worth using in the first place.

The Semantic Web’s Adoption Problem

If you’ve worked with knowledge graphs, you know this story. You show someone a beautifully reasoned inference chain -- how (Mehdi, founded, BrandPulse) plus the ontology’s domain/range constraints automatically infers that Mehdi is a Person and BrandPulse is a Company. They’re impressed. Then you show them the SPARQL they’d need to write to query it, and their eyes glaze over.

The semantic web has always had a marketing problem disguised as a usability problem. The underlying ideas -- triples, ontologies, inference, linked data -- are elegant. But the tooling has historically assumed that everyone using it has a PhD in knowledge representation.

I don’t think the answer is to dumb it down. Stripping away the ontology layer to make things “simpler” defeats the purpose. Without formal semantics, you just have a labeled property graph -- fine for some use cases, but you lose inference, auto-typing, and schema validation. You lose the reason knowledge graphs are more powerful than a relational database in the first place.

The answer is to keep the semantic rigor underneath and put a natural-language interface on top.

What Knowledge Graphs Actually Give You

For readers who haven’t worked with these technologies before, let me explain why anyone would bother with all this machinery instead of just using a regular database.

A knowledge graph stores facts as triples: subject, predicate, object.

(Mehdi, founded, BrandPulse)

(BrandPulse, industry, AI)

(Alice, worksAt, BrandPulse)

Each triple is a fact. Together, they form a graph you can traverse. Want to know who works at companies Mehdi founded? Follow the edges. No JOINs, no pre-designed queries, no schema migration when you add a new relationship type.

But the real power comes from ontologies -- formal descriptions of what types of things exist and how they can relate.

Why Ontologies Matter

An ontology doesn’t just describe data. It enables reasoning.

Define this:

Class: Person

Class: Company

Property: founded (domain: Person, range: Company)

Now when someone adds (Mehdi, founded, BrandPulse), the system automatically infers that Mehdi is a Person and BrandPulse is a Company. This is called auto-typing, and after working with it for over a decade, I can tell you it’s one of those capabilities that seems minor until you realize how much manual annotation it eliminates at scale.

Ontologies also give you constraint validation (is this triple even valid given the schema?), cross-domain reasoning (if a Person can found a Company, and a Company has Employees, what can we infer about the relationship between founders and employees?), and interoperability (your ontology and mine can be linked through shared upper ontologies).

The Multi-Ontology Problem

Real-world knowledge doesn’t fit into one neat schema. This is something I’ve dealt with repeatedly across projects. A hospital needs a medical ontology, an organizational one, and a geographic one. A research lab might combine domain-specific ontologies with FOAF, Dublin Core, and Schema.org.

These ontologies overlap. Both FOAF and Schema.org define “Person.” When your data says “Person,” which one do you mean? When two ontologies define different properties with the same label, which takes precedence?

In KeplAI, each imported ontology lives in its own named graph inside Apache Jena Fuseki. URI resolution searches across all loaded ontologies. If there’s a unique match, it resolves. If two ontologies claim the same label, the system raises a conflict rather than silently picking one. This is the kind of design decision that comes from having been burned by silent ontology collisions more than once.

What LLMs Finally Make Possible

I’ve watched the semantic web community struggle with two problems for years. LLMs don’t solve them perfectly, but they solve them well enough to fundamentally change the equation.

Populating the Graph

Knowledge graph construction has always been the bottleneck. I’ve used every approach:

• Manual curation -- accurate but impossibly slow. I’ve spent weeks annotating corpora for research projects that produced graphs with a few thousand triples.

• Rule-based extraction -- fragile. Change the sentence structure and your regex pipeline breaks.

• Supervised NER/RE models -- requires labeled training data, which requires... manual curation. A chicken-and-egg problem.

LLMs break this cycle. Give GPT-4 a paragraph and an ontology schema, and it extracts structured triples that actually conform to the schema:

triples = await kg.extract_and_store(

"Mehdi founded BrandPulse in 2024. The company focuses on AI.",

mode="strict" # Constrained to ontology schema

)

In “strict” mode, extraction is constrained to properties defined in your ontology -- the LLM can only produce triples that match your schema. In “open” mode, it discovers relationships freely, which is useful for exploratory graph building.

But extraction alone isn’t enough. Text says “M. Allahyari” and the graph already has “Mehdi Allahyari” -- are they the same entity? This entity disambiguation problem is something I’ve worked on extensively. KeplAI uses vector embeddings (OpenAI’s embedding model + Qdrant vector store) to match extracted entities against existing ones. The user sees candidates ranked by similarity score and can confirm or reject. It’s not perfect -- “Apple” the company vs. “apple” the fruit still requires contextual reasoning that embeddings alone can’t fully capture -- but it handles the 80% case that used to require manual reconciliation.

Querying the Graph

SPARQL is a powerful query language. I write it fluently after years of practice. But I also know that asking a domain expert to write this is unreasonable:

PREFIX entity: <http://keplai.io/entity/>
PREFIX ontology: <http://keplai.io/ontology/>
SELECT ?company WHERE {
  GRAPH ?g {
    entity:Mehdi ontology:founded ?company .
    ?company ontology:industry "AI" .
  }
}

They want to ask: “What AI companies did Mehdi found?”

Translating natural language to SPARQL is where I’ve spent the most engineering effort in KeplAI, because this is where naive LLM usage falls apart spectacularly.

The core problem: LLMs invent predicates. Ask GPT-4 to generate SPARQL for “when was Tom Hanks born?” and it’ll confidently produce ontology:birthDate -- even when your graph uses ontology:bornOn. The LLM’s world knowledge overrides the schema context you provided. It’s the same hallucination problem, just manifesting in a structured output.

KeplAI’s NLQ engine addresses this with a multi-stage pipeline:

1. Relation mapping -- Before generating SPARQL, an LLM call maps natural-language phrases (”works at,” “born in”) to actual predicates in your graph. This produces explicit mappings that get injected into the generation prompt.

2. Entity resolution -- Entity mentions are extracted from the question and resolved against the graph via vector similarity. “Tom Hanks” becomes entity:ThomasJeffreyHanks (or whatever your graph uses).

3. Schema-grounded generation -- The SPARQL generation prompt includes the full property list (with descriptions), the entity mappings, the relation mappings, and explicit instructions to use only listed predicates.

4. Predicate validation -- After generation, every URI in the output SPARQL is checked against the allowed set. If the LLM invented ontology:birthDate when only ontology:bornOn exists, it’s flagged.

5. Self-repair -- Invalid predicates trigger a repair call: “Your query uses these invalid predicates. Here are the allowed ones. Fix it.” This catches the 10-15% of queries where the LLM ignores the schema despite explicit instructions.

Is it perfect? No. Complex multi-hop queries still trip up sometimes. But for the vast majority of questions a domain expert would ask, it produces correct SPARQL -- and it shows the generated query alongside the results, so power users can verify and edit.

Use Cases Where This Actually Matters

Research Knowledge Management

This is closest to my own experience. A researcher imports domain ontologies (biomedical, legal, environmental), then feeds papers and documents through the extraction pipeline. The knowledge graph grows semi-automatically. They can ask “Which genes are associated with both diabetes and cardiovascular disease?” and get answers grounded in extracted data, with provenance tracking showing which paper each fact came from.

Enterprise Knowledge Unification

Organizations have knowledge trapped in wikis, Confluence pages, Slack threads, and people’s heads. A knowledge graph can unify this. Extract triples from documentation, connect them with organizational ontologies, and you have a queryable map of institutional knowledge. When someone leaves the company, their knowledge doesn’t leave with them.

Compliance and Auditing

Every triple in KeplAI can carry provenance: source document, extraction timestamp, method (manual vs. AI-extracted). In regulated industries -- healthcare, finance, legal -- being able to trace every fact back to its source isn’t a nice-to-have. It’s a requirement.

AI-Powered Applications

This is where I think the biggest opportunity lies. RAG (Retrieval-Augmented Generation) typically uses vector search over chunks of text. But knowledge graphs offer something vector search can’t: structured reasoning. Instead of retrieving “similar text,” you retrieve facts and their logical connections. An LLM grounded in a knowledge graph doesn’t just find relevant passages -- it follows relationship chains and provides answers with explicit provenance.

Hard-Won Technical Insights

A few things I want to share from building this that aren’t obvious from the outside:

Named graphs are essential but the ecosystem barely supports them. Almost every SPARQL tutorial teaches you to query the default graph. In practice, if you’re managing multiple ontologies with data isolation, everything lives in named graphs. This means every query needs a GRAPH ?g { ... } wrapper. Forget it, and you get zero results with zero helpful error messages. KeplAI auto-injects GRAPH clauses when the LLM forgets them -- a safety net born from painful debugging sessions.

The LLM-to-SPARQL “last mile” is harder than NL-to-SQL. SQL has a relatively flat structure -- tables, columns, JOINs. SPARQL has PREFIX declarations, URI resolution, named graphs, blank nodes, OPTIONAL patterns, FILTER expressions, and the RDF data model underneath. The LLM needs to get all of this right simultaneously. The relation mapping and predicate validation layers exist because a single wrong URI means the query silently returns nothing.

Ontologies compound in value over time. This is something you only appreciate after maintaining a knowledge graph for months or years. Early on, defining an ontology feels like overhead. Six months in, when auto-typing has correctly classified thousands of entities and inference has surfaced relationships you never explicitly stated, the upfront investment pays for itself many times over.

Entity disambiguation remains the hardest unsolved problem. After years of working on this, I’m convinced that pure vector similarity gets you ~80% of the way. The remaining 20% -- contextual ambiguity, cross-language entities, temporal references -- requires hybrid approaches combining embeddings with graph structure and contextual reasoning. This is active work.

The Architecture

For those who want to look under the hood:

KeplAI is SDK-first. The Python SDK (keplai) is the core -- it manages the graph, ontologies, and AI features and can be used standalone. The REST API (FastAPI) and Web UI (React + TypeScript) are layers on top.

The stack:

• Apache Jena Fuseki -- standards-compliant RDF triplestore with SPARQL endpoint and OWL reasoning. The SDK manages Fuseki’s Docker lifecycle automatically.

• OpenAI GPT-4 -- powers extraction, NL-to-SPARQL generation, and result explanation.

• Qdrant -- vector similarity search for entity disambiguation.

• OWL/RDFS reasoning -- built into the triplestore, so inference happens at the data layer, not the application layer.

The web UI provides a dashboard, triple management with batch operations, an ontology editor with multi-ontology support, a text extraction interface, a natural language query page, and an interactive force-directed graph explorer.

Open source under Apache 2.0: github.com/mallahyari/keplai.

The Bigger Picture

I’ve been in the semantic web world long enough to have seen multiple hype cycles come and go. Linked Data. The original Semantic Web vision. Knowledge graphs in enterprise. Each wave brought real progress but never achieved mainstream adoption.

This time feels different, and the reason is LLMs.

The fundamental thesis: LLMs are great at understanding language but hallucinate facts. Knowledge graphs are great at storing facts but are hard to query naturally. They’re complementary in a way that’s almost too clean.

LLMs as the interface to structured knowledge -- with the knowledge graph providing ground truth, provenance, and reasoning, and the LLM providing the natural-language bridge -- is, I believe, how the next generation of knowledge-intensive AI applications will be built. Not chatbots that make things up, but systems that reason over verified facts and can show their work.

KeplAI is my attempt to make that vision practical today. It’s not finished -- the NLQ pipeline needs more work on complex queries, the disambiguation could be smarter, and there are a dozen features on the roadmap. But it’s usable now, and the best way to improve it is for people to use it and push against the edges.

If you’ve been curious about knowledge graphs but put off by the tooling, or if you’re a semantic web veteran wondering how LLMs fit into the picture, give it a try.

KeplAI is open source and available at github.com/mallahyari/keplai.

If you’ve been paying attention to the open-source AI space lately, you’ve probably noticed the explosion of personal AI assistants. It started with OpenClaw — a powerful, feature-rich agent that took GitHub by storm with 240k+ stars. Then came the inevitable: everyone wanted a lighter version.

ZeroClaw rewrote it in Rust. PicoClaw rebuilt it in Go for $10 hardware. IronClaw focused on security with WebAssembly sandboxing. NanoClaw stripped it to 500 lines.

I tried several of them. And then I found Nanobot — a 4,000-line Python alternative — and stopped looking.

Here’s why.

The Problem With OpenClaw

Don’t get me wrong — OpenClaw is impressive. It supports dozens of messaging platforms, has 100+ skills, and can genuinely automate complex workflows. But it comes at a cost:

• 430,000+ lines of TypeScript

• 70+ dependencies

• 52+ modules and 53 config files

• Individual files that run thousands of lines deep

I wanted a personal assistant I could own — not just use, but understand end-to-end, modify confidently, and extend without fear of breaking some distant module I’d never read. OpenClaw wasn’t that.

The Alternatives Didn’t Quite Fit Either

The community responded with lighter alternatives, and they’re genuinely impressive:

But here’s my issue: I think in Python. My entire ML/AI workflow is Python. When I look at a Rust codebase, I can appreciate the engineering — but I can’t casually add a new tool on a Saturday morning. And the 500-line options, while elegant, sacrifice too many features to be practical as a daily driver.

Enter Nanobot: The Sweet Spot

Nanobot delivers the core functionality of OpenClaw in roughly 4,000 lines of Python. That’s 99% smaller. But the line count isn’t the real story — what matters is that you can read the entire codebase in an afternoon and understand every decision.

Here’s what’s packed into those 4,000 lines:

• 13 chat channels — Telegram, Discord, Slack, WhatsApp, Email, Matrix, and more

• 19 LLM providers — Anthropic, OpenAI, DeepSeek, Groq, Gemini, OpenRouter...

• 13 built-in tools — file ops, shell, web search, scheduled tasks, background agents

• Persistent memory — the bot remembers you across conversations

• A skill system — drop a markdown file in a folder and your bot gains new abilities

• MCP support — plug into the Model Context Protocol ecosystem

And it’s not just small — it’s clean. The architecture follows a simple principle: channels don’t know about the AI, and the AI doesn’t know about channels. Everything talks through a message bus.

The Architecture (in 30 Seconds)

The whole system is three layers connected by async queues:

A message comes in from any platform. The bus routes it to the agent loop. The agent builds a prompt (with your conversation history, long-term memory, and any active skills), calls the LLM, executes tools if needed, and sends the response back through the bus to whichever platform you’re on.

Here’s what a single request looks like end-to-end:

That’s it. The entire flow.

What Makes It Easy to Customize

Adding a tool is ~30 lines

Want your assistant to do something new? Every tool is a small class with one method:

class MyTool(Tool):
    name = "check_stocks"
    description = "Check current stock prices"
    parameters = {
        "type": "object",
        "properties": {
            "symbol": {"type": "string", "description": "Stock ticker symbol"}
        },
        "required": ["symbol"]
    }

    async def execute(self, params: dict) -> str:
        symbol = params["symbol"]
        # Your logic here — call an API, query a database, anything
        price = await fetch_stock_price(symbol)
        return f"{symbol}: ${price}"

Register it in one line, and your bot can now check stock prices. No plugin system to learn, no config files to wrestle with, no build step.

Adding a skill is just a markdown file

Skills inject knowledge into your bot’s system prompt. Want your assistant to be an expert at managing your home automation?

Create ~/.nanobot/workspace/skills/smart-home/SKILL.md:

# Smart Home Assistant

You can control the user's home devices using the exec tool.
- Lights: `hue-cli set <room> <brightness>`
- Thermostat: `nest-cli temp <degrees>`
- Always confirm before changing settings.

That’s a skill. Drop the file in the folder, and your bot knows how to manage your smart home on the next message.

The memory system is beautifully simple

Nanobot keeps two files:

• MEMORY.md — long-term facts (”User prefers Python. Lives in San Francisco. Works on ML projects.”)

• HISTORY.md — timestamped event log

MEMORY.md gets injected into every prompt, so your assistant always knows who you are. When conversations get long, the agent summarizes old messages and saves the important bits. No vector database, no embeddings, no infrastructure — just markdown files you can read and edit yourself.

The Honest Trade-offs

Nanobot isn’t trying to replace OpenClaw for everyone. Here’s where it intentionally makes different choices:

• No GUI — it’s channels + CLI. If you want a web dashboard, look elsewhere.

• Fewer built-in skills — OpenClaw has 100+; Nanobot has 8 (but adding your own is trivial).

• Single-process — it’s one Python process, not a distributed system. For a personal assistant, that’s a feature, not a bug.

• File-based storage — no database. Sessions are JSONL, memory is markdown, config is JSON. Simple and portable, but not built for multi-user scale.

For a personal assistant that you run for yourself, these trade-offs are exactly right.

Why This Matters

There’s a broader point here that goes beyond any single project.

We’re in an era where AI tools are getting more powerful every month. The models improve, the APIs get cheaper, the capabilities expand. In this environment, the best AI assistant isn’t the one with the most features — it’s the one you can evolve alongside the models.

When Claude gets better at reasoning, I want to adjust my agent’s tool execution strategy. When a new MCP server drops for my favorite service, I want to plug it in. When I have a weird personal workflow that no one else would build a plugin for, I want to code it myself in an hour.

That requires a codebase I can hold in my head. For me, that’s 4,000 lines of Python — not 430,000 lines of TypeScript or a Rust binary I’d need to recompile.

Getting Started

If this resonates, here’s the quickest path:

# Install
pip install nanobot

# First-time setup (creates config + workspace)
nanobot onboard

# Chat interactively
nanobot agent

# Or run as a multi-channel gateway
nanobot gateway

Edit ~/.nanobot/config.json to add your API keys and enable channels.

Final Thought

The claw family has given us incredible options. OpenClaw proved the concept. ZeroClaw and IronClaw showed us what’s possible in Rust. PicoClaw proved AI agents can run on tiny hardware.

Nanobot showed me that sometimes the most powerful tool is the one simple enough to be truly yours.

If you’re building your own personal AI assistant or have thoughts on the claw ecosystem, I’d love to hear from you. Drop a comment or reach out, I’m always happy to talk about this stuff.

Most tutorials show you a single LLM call that converts a question into SQL. That works on toy examples. It falls apart the moment a real user touches it.

Real databases have dozens of tables. Real users ask vague, ambiguous questions. And real SQL agents need to handle errors gracefully, retry intelligently, stream responses in real time, and never, ever run a DROP TABLE on your production database.

In this post, I’ll walk you through how I designed and built a production-ready SQL agent, covering the architecture, the key design decisions, and the lessons learned along the way. We’ll go light on boilerplate and heavy on the why.

The full code (backend + frontend with live visualizations) is on GitHub: github.com/mallahyari/langgraph-sql-agent

The Stack

• LangGraph: multi-node agent orchestration with conditional routing and retry loops

• GPT-4o: reasoning, SQL generation, and natural language synthesis

• FastAPI + Server-Sent Events: async streaming API

• SQLite: database backend (the architecture is database-agnostic)

• React + Vega-Lite: frontend with auto-generated charts

Why a Multi-Agent Approach?

The naive approach is one LLM call: “Here’s my schema. Here’s the user’s question. Write SQL.”

This breaks in predictable ways:

• The LLM picks the wrong tables when your database has many of them

• Vague questions like “show me sales” generate ambiguous queries

• When a query fails at runtime, there’s no recovery path

• You have zero visibility into what went wrong or why

The insight is that text-to-SQL isn’t one problem, it’s several smaller ones chained together. When you decompose it into specialized nodes, each with a single job, you get a system that’s easier to debug, easier to improve, and resilient to failure.

Think of it as a pipeline of domain experts:

Each of these is a node in a LangGraph StateGraph. The graph connects them with conditional edges that handle routing, retries, and error recovery automatically.

The Architecture

Here’s the full workflow:

The retry loop is the key architectural decision: if the SQL fails validation or fails at runtime, the graph routes back to the SQL generator with the error message injected into the conversation. The LLM sees what went wrong and corrects itself , up to 3 times before giving up gracefully.

This is what separates a demo from a system you can actually deploy.

How LangGraph Orchestrates It

LangGraph is built on the concept of a StateGraph, a directed graph where each node reads from and writes to a shared state object. Here’s the shape of that state:

class AgentState(TypedDict):
    user_query: str
    refined_query: Optional[str]
    relevance: str
    selected_tables: List[str]
    generated_sql: str
    query_result: List[Dict[str, Any]]
    query_error: Optional[str]
    is_valid_sql: bool
    retry_count: int
    validation_error: Optional[str]
    natural_response: str
    needs_visualization: bool
    visualization_spec: Optional[Dict[str, Any]]
    logs: Annotated[List[str], operator.add]
    steps: Annotated[List[str], operator.add]

One thing worth calling out: the Annotated[List[str], operator.add] on logs and steps. This tells LangGraph to append to these lists rather than overwrite them. Every node contributes its own entries, and you end up with a full audit trail of what happened at each step, invaluable for debugging.

Routing between nodes is handled by plain Python functions:

def route_after_execution(state: AgentState) -> str:
    if state.get("query_error") and state.get("retry_count", 0) < MAX_RETRIES:
        return "sql_generator"
    return "response_synthesizer"

Simple, readable, and easy to change. The orchestration logic lives in the graph definition, completely separate from the agent implementations.

Key Design Decisions

1. Use Function Calling for Structured Decisions

Any time a node needs to produce a categorical output, “is this relevant?”, “which tables?”, “does this need a chart?” — use OpenAI’s function calling with an enum constraint instead of parsing free text.

Free text parsing is fragile. The model might say “Yes, this is relevant” or just “Relevant” or “I believe the query relates to...”, you end up writing brittle string matching. Function calling gives you guaranteed structured output:

"relevance": {
    "type": "string",
    "enum": ["relevant", "irrelevant"]
}

One call, guaranteed valid result. Use this pattern for every decision node in your graph.

2. Always Ground-Truth Check LLM Outputs

The table selector asks the LLM which tables are needed, then does this:

valid_tables = [t for t in args["tables"] if t in all_tables]

That one line prevents a surprisingly common failure: LLMs confidently hallucinate table names that don’t exist. Always cross-reference any LLM output that refers to real-world entities (table names, column names, file paths) against the actual ground truth before passing it downstream.

Same principle applies to column names in the SQL generator, feed the LLM the exact CREATE TABLE schema, not a description of it.

3. Raise Temperature on Retries

At temperature=0, GPT-4o is deterministic. If the first SQL query fails and you retry with the same temperature, you get the exact same broken query. Set temperature to 0.3 on retries, just enough variation that the model explores a different approach, without going off the rails.

4. Inject Error Context Into the Retry Conversation

On retry, don’t just run the node again. Pass the failed query and the error message back to the SQL generator as prior conversation turns:

System: [schema + instructions]

User: [original query]

Assistant: [the broken SQL that failed]

User: "That query failed with: no such column 'TotalRevenue'. Please fix it."

The LLM now has the full context of what it tried and why it failed. This dramatically improves retry success rate compared to starting fresh.

5. Validate SQL Before It Touches Your Database

A safety layer that checks for destructive keywords (DROP, DELETE, TRUNCATE, UPDATE, etc.) using regex word boundaries is non-negotiable. This blocks both accidental and malicious writes before anything reaches the database.

pattern = r'\b' + keyword + r'\b'

Word boundaries matter, without them, a column named dropship_count would trigger a false positive.

6. Truncate Large Results Before Synthesis

Some queries return thousands of rows. Feeding all of them to the synthesizer is expensive and often exceeds context limits. Truncate to a reasonable character limit before synthesis. The synthesizer’s job is to summarize, not to enumerate every row, so you rarely lose anything meaningful.

7. Thread IDs for User Session Isolation

LangGraph’s MemorySaver checkpointer scopes conversation history to a thread_id. Pass a unique ID per user session, and multiple concurrent users share one deployment with fully isolated state. No session collisions, no state bleed-through.

For production, swap MemorySaver for a persistent checkpointer backed by Redis or Postgres so history survives server restarts.

Streaming: Why It Matters More Than You Think

A SQL query can take 3-5 seconds end-to-end. Without streaming, your user stares at a blank screen and assumes something broke.

The architecture uses two streaming modes simultaneously via LangGraph’s astream:

• updates mode: fires after each node completes, sending structured data (SQL generated, rows returned, etc.) that the frontend can display progressively

• custom mode: fires on every LLM token during synthesis, enabling word-by-word text streaming

The result is a UI that feels responsive and alive even during a multi-second pipeline. The user sees the SQL appear, then the row count, then the explanation streaming in, then the chart, all without waiting for the full workflow to finish.

This is delivered over Server-Sent Events (SSE) via a FastAPI StreamingResponse. SSE is simpler than WebSockets for this use case: unidirectional, HTTP-native, no handshake overhead.

One gotcha: if you run behind Nginx, add X-Accel-Buffering: no to your response headers. Without it, Nginx buffers the entire response and defeats the purpose of streaming entirely.

The Visualization Layer

One of the more interesting parts of the system is the automatic chart generation. After synthesizing a text response, a visualization planner node decides whether a chart would add value, checking for explicit requests (”plot this”, “show a chart”) and analyzing the data shape (time series, categorical breakdown, single values).

If a visualization makes sense, a visualization generator node calls GPT-4o in JSON mode to produce a Vega-Lite spec directly from the query results. The frontend renders it instantly.

This means a query like “show me monthly revenue over the past year” automatically produces a line chart, with no hardcoded chart types and no user configuration required. The LLM figures out the right encoding, axes, and title from the data itself.

Vega-Lite is a great fit here because it’s declarative JSON, the LLM can produce it reliably in JSON mode, and the frontend renders it without needing to interpret any code.

What the Frontend Does

The backend streams JSON events. The React frontend listens and progressively renders:

1. A “thinking” indicator while nodes are running

2. The generated SQL in a syntax-highlighted code block (so users can inspect it)

3. The row count and raw data in a table

4. The natural language explanation, streaming token by token

5. The Vega-Lite chart, rendered automatically when the visualization spec arrives

Showing the SQL is a deliberate choice. It builds trust, users can see exactly what query was run, verify it makes sense, and catch errors. It also makes the system feel transparent rather than like a black box.

Common Failure Modes (And How to Avoid Them)

Hallucinated column names. The LLM makes up a column that doesn’t exist. Fix: always pass the exact CREATE TABLE DDL as schema context, not a paraphrased description.

Overly broad table selection. The table selector includes every table “just in case,” bloating the schema context. Fix: require the LLM to justify each selected table, or use strict function calling with an explicit count limit.

ORDER BY placement in UNION queries. SQLite requires ORDER BY to appear after the final SELECT in a UNION ALL. The LLM often puts it in the wrong place. Fix: add this as an explicit rule in the SQL generator’s system prompt.

Markdown in SQL output. The model wraps its SQL in ```sql ``` fences. Always strip these before executing.

Retry storms. Without a hard retry cap, a broken query can loop indefinitely. Enforce a maximum retry count in state and route to a graceful error response when exceeded.

Going Further

This architecture is a foundation. A few directions worth exploring:

Scale to larger schemas. With hundreds of tables, feeding even table names to the LLM becomes unwieldy. Add a vector similarity search step to retrieve semantically relevant tables before the table selector node runs.

Row-level security. The executor currently runs all queries with the same database credentials. In a multi-tenant system, inject user-specific filters or use separate database roles per user.

Human-in-the-loop. LangGraph has native support for breakpoints and interrupt_before, you can pause the graph before execution and require a human to approve the generated SQL. Useful in high-stakes environments.

Swap the LLM. The OpenAI client lives in a single service file. Replace it with Anthropic’s Claude, a local Ollama model, or any OpenAI-compatible endpoint. The rest of the system stays the same.

Persistent memory. Right now, conversation history lives in memory and resets on restart. Swap MemorySaver for LangGraph’s AsyncPostgresSaver for durable multi-session memory.

The Full Picture

What makes this system work in practice isn’t any single clever trick, it’s the combination:

• Specialization: each node does one thing and does it well

• Retry with context: the graph corrects its own mistakes with full error awareness

• Safety by design: SQL is validated before it ever reaches the database

• Streaming at every layer: users see progress, not spinners

• Grounded outputs: LLM results are always checked against reality before use

• Separation of concerns: orchestration logic lives in the graph, not in the nodes

The LangGraph pattern, decompose into nodes, connect with conditional edges, add retry loops, generalizes far beyond SQL. Any problem where a single LLM call is too brittle is a candidate for this architecture.

The complete code for both the backend and the React frontend with live Vega-Lite visualization is available here:

github.com/mallahyari/langgraph-sql-agent

If you build something with this or adapt it for your own database, I’d love to hear what you changed and why.

"From Stanford professors to OpenAI scientists, unicorn founders to quantum-tech pioneers, the future of AI is gathering in one place— and you're invited."

Mark your calendars for July 13-17, 2025, because the epicenter of the AI world will be at the Santa Clara Convention Center. GenAI Week Silicon Valley 2025 is shaping up to be the largest, most influential AI gathering of the decade. With over 30,000 attendees expected, this will be a glimpse into the future of artificial intelligence and its transformative impact across every industry.

An Unprecedented Lineup of AI Luminaries

The speaker list reads like a who's who of AI innovation:

• Jason Wei,, OpenAI scientist behind GPT-3

• Arvind Jain, CEO of Glean ($7.2B valuation)

• Edward Oates, Co-Founder of Oracle

• Soumya Batra, core author of Llama 2 & 3

• Richard Socher, CEO of You.com ($900M valuation)

And that's just scratching the surface. From startup founders pushing the boundaries of what's possible, to leaders at tech giants like Microsoft, Google, and Meta, the collective brainpower at this event is staggering.

For startups, this is your chance to shine on a global stage.

The Founder's Pitch Package offers the opportunity to present your vision to a room full of top-tier investors and decision-makers.

📢 Do you want to pitch your startup on stage?

Apply here:

Apply here!

（Reminder, purchase the FOUDNERS PITCH PACKAGE at the same time)

📈 Are you a VC attending the event?

If you'd like curated intros, private sessions, or exclusive access — fill this:

For VCs

📚 Still deciding which day(s) to attend? Here more reasons:

100+ Sessions Covering the Future of AI

With over 100 tactical sessions, you'll gain practical insights into:

• Advanced agent frameworks

• AI monetization strategies

• Ethical considerations in AI development

• Industry-specific AI applications

• The intersection of AI and quantum computing

Whether you're a developer, entrepreneur, investor, or simply AI-curious, there's something here to expand your horizons and spark new ideas.

Full Speaker Lineup (One-Stop Guide)：

All speakers listed here:

Coolest demo - Alef flying cars

Global Networking on an Unparalleled Scale

"With attendees from over 30 countries, it'll be buzzing with energy, ideas, and opportunities." - Jimmy, Cofounder of GPTDAO

The value of connections made at events like this cannot be overstated. GenAI Week 2025 brings together a truly global community of AI enthusiasts, practitioners, and visionaries. The potential for collaboration, investment, and career advancement is immense.

Exclusive Discount for Our Readers

We're excited to offer our TwoSetAI audience an exclusive 15% discount on tickets. Use coupon code TWOSETAI when registering through these links:

• Luma: https://lu.ma/genaiweek2025?coupon=TWOSETAI

• Eventbrite: www.eventbrite.com/e/1301648458579/?discount=TWOSETAI

• QR codes for easy registration:

  

Limited spot free ticket!

For our MLNotes and TwoSetAI audience, we have several free tickets available. For a chance at a free ticket, email angelina@oscr.tech before 6pm PST on 7/6. Limited quantities available, so act fast!

Hope to see you there!

Claim your spot now with our exclusive discount!

🛠️✨ Happy practicing and happy building! 🚀🌟

Thanks for reading our newsletter. You can follow us here: Angelina Linkedin or Twitter and Mehdi Linkedin or Twitter.

Source of image:
SWR: https://milvus.io/docs/v2.5.x/assets/advanced_rag/sentence_window.png

🌈 Our RAG course: https://maven.com/angelina-yang/mastering-rag-systems-a-hands-on-guide-to-production-ready-ai

 📚 Also if you'd like to learn more about RAG systems, check out our book on the RAG system: You can download for free on the course site:
https://maven.com/angelina-yang/mastering-rag-systems-a-hands-on-guide-to-production-ready-ai

🦄 Any specific contents you wish to learn from us? Sign up here: https://noteforms.com/forms/twosetai-youtube-content-sqezrz

🧰 Our video editing tool is this one!: https://get.descript.com/nf5cum9nj1m8

📽️ Our RAG videos: https://www.youtube.com/@TwoSetAI

📬 Don't miss out on the latest updates - Subscribe to our newsletter:

The MLnotes Newsletter

MLnotes delivers bite-sized content covering diverse aspects of AI and ML, from real-world applications to entrepreneurship and careers in AI. Together, we can foster knowledge sharing and alleviate information anxiety amidst the rapid advancements in AI!

By Mehdi Allahyari

(He shared a backlink/SEO hack that he personally is using, which is totally thinking outside of the box, check it out below!) 👇
(He also shared deep insight around whether SEO is for you OR NOT! see below!) 👇

How’s SEO evolving in the age of AI?

"I think there's a few factors. One we can get into is building a foundation about actually thinking about starting to rank on LLMs," says Sam Dunning, founder of Breaking B2B.

This statement captures the current state of SEO -

it's not dying, it's evolving.

The rise of AI and Large Language Models (LLMs) has undoubtedly shaken up the world of search engine optimization. Some have even proclaimed the death of SEO as we know it.

However, the reality is far more nuanced.

SEO isn't dead; it's undergoing a transformation, adapting to the new landscape of AI-driven search.

Sam's insights reveal that while traditional SEO metrics like traffic are changing, with some clients seeing up to a 20% decline in traffic from traditional search, new opportunities are emerging.

The key is to understand these changes and adapt our strategies accordingly.

Google remains the undisputed king of search.

Despite the buzz around AI search tools, Google remains the undisputed king of search. Sam points out,

This statistic is crucial for SEO professionals and businesses alike. While it's important to prepare for the future of AI-driven search, we can't ignore the present reality.

Google is still the primary source of organic traffic for most websites, and optimizing for Google's algorithms remains a critical part of any comprehensive SEO strategy.

Adapting SEO Strategies for AI-Driven Search

While Google still dominates, the rise of AI search tools like ChatGPT can't be ignored.

Sam advises,

"It's about building that foundation for LLMs. So not disregarding Google. Still need to work on it because the chances are when they fully roll out Google AI mode in a year or so (it’s already out!), it would likely take a lot of those ranking factors across, but build up a foundation to start ranking on chatGPT, and similar as well so you don't get kind of caught behind."

This dual approach - optimizing for both traditional search engines and AI-powered tools - is likely to become the new norm in SEO.

It requires a deeper understanding of how AI interprets and ranks content, as well as a willingness to experiment with new strategies.

Understanding your Customer before Content Creation is the key.

One aspect of SEO that remains unchanged, regardless of the technology driving search, is the importance of understanding your audience. —> This has never changed!

Sam emphasizes,

"If the content you're putting out just ranks, but it doesn't actually resonate with your dream clients, expensive problems, motivations, jobs to be done, address their common questions, position your product as a painkiller, and show why you and it's almost a waste of time."

This insight tells me that thorough customer research should be top priority in your SEO strategy.

It's not just about ranking for keywords; it's about creating content that truly resonates with your target audience's needs, pain points, and motivations.

This customer-centric approach not only helps with SEO but also improves conversion rates and overall marketing effectiveness.

Technical SEO? Do your users understand your content?

While technical SEO elements remain important, Sam's approach emphasizes the need to balance these with user-focused content. He states,

"So many SEOs talk about the technical things, the step by step processes, but they forget that we're actually selling complex solutions to prospects that have jobs to be done, struggling moments, etcetera."

This balance is crucial in the evolving SEO landscape. Technical optimizations help search engines understand and rank your content, but it's the user-focused elements that keep visitors engaged and encourage conversions.

As AI becomes more sophisticated in understanding user intent, this balance will likely become even more important.

Backlinks and brand mentions still works…

Despite the changes in search technology, some fundamental SEO principles remain crucial. Sam highlights the continued importance of backlinks and brand mentions, especially in the context of AI search.

He notes,

"They evaluated 75,000 brands. And that evaluation, it showed that the ones that are ranking the most consistently on AI overviews were getting consistent brand mentions on external websites."

This insight suggests that while the mechanisms of search are changing, the underlying principles of authority and relevance - as demonstrated through backlinks and brand mentions - continue to play a significant role.

It's a reminder that SEO isn't just about on-page optimization, but also about building a strong presence across the web.

Strategies for Ranking in Both Traditional and AI-Driven Search

Sam provides several strategies for optimizing content for both traditional and AI-driven search:

Read more

"Software is changing again, and I think it's changing quite fundamentally. I think roughly speaking, software has not changed much on such a fundamental level for 70 years, and then it's changed I think about twice quite rapidly in the last few years." - Andrej Karpathy

These words from Andrej Karpathy, former director of AI at Tesla, set the stage for a profound transformation in the world of software development. His recent keynote talk at the Startup School in San Francisco is super inspiring.

As AI engineers, data scientists, and tech professionals, we find ourselves at the forefront of this revolution. But with great power comes great responsibility, and the specter of AI risk looms large over our exciting new frontier.

The Evolution of Software: From 1.0 to 3.0

Software 1.0: The Traditional Paradigm We All Know

For decades, software development meant writing explicit instructions for computers in languages like C++, Python, or Java. Karpathy refers to this as "Software 1.0" – the foundation of our digital world.

Software 2.0: The Rise of Neural Networks

The advent of deep learning ushered in the era of "Software 2.0." Instead of writing explicit code, we began training neural networks, effectively programming through data and optimization algorithms. This shift marked a significant departure from traditional software development practices.

Software 3.0: Programming in Natural Language

Now, we stand at the precipice of "Software 3.0" – a paradigm where we program Large Language Models (LLMs) using natural language prompts. This revolutionary approach democratizes programming, but it also introduces new challenges and potential AI risks that we must carefully navigate.

LLMs: The New Operating Systems

Why LLMs Are More Than Just Another Tool

Karpathy draws a compelling analogy between LLMs and operating systems:

"LLMs don't only have properties of utilities. I think it's also fair to say that they have some properties of fabs1, and the reason for this is that the capex2 required for building LLM is actually quite large."

This perspective shifts our understanding of LLMs from mere tools to fundamental infrastructure. Just as operating systems provide a platform for applications, LLMs are becoming the foundation for a new generation of AI-powered software.

The Utility-Like Nature of LLM Providers

LLM providers like OpenAI, Google (with Gemini), and Anthropic are emerging as utility-like entities. They invest heavily in infrastructure (akin to power plants) and offer metered access to their intelligence via APIs. This utility model introduces new considerations for AI safety and regulation, as we become increasingly dependent on these "intelligence grids."

The Psychology of LLMs: Understanding Our New Digital Colleagues

LLMs as "People Spirits"

Karpathy introduces a fascinating concept: LLMs as "people spirits" – stochastic simulations of human-like intelligence. This anthropomorphic view helps us understand both the strengths and limitations of these systems.

Cognitive Quirks and Limitations

While LLMs possess superhuman capabilities in certain areas, they also exhibit cognitive deficits:

• Hallucinations and confabulation

• Jagged intelligence (excelling in some areas while failing at simple tasks)

• Lack of persistent memory

Understanding these limitations is crucial for mitigating AI risk and designing effective human-AI collaboration systems.

Designing LLM Apps with Partial Autonomy

The Autonomy Slider: Finding the Right Balance

Karpathy introduces the concept of an "autonomy slider" in LLM applications. This allows users to control the level of AI involvement, from simple autocomplete to full-fledged autonomous agents. Striking the right balance is key to maximizing productivity while maintaining human oversight.

We can Model After Cursor for AI-Assisted Coding

The Cursor app exemplifies effective LLM integration in software development:

1. Context management

2. Orchestration of multiple LLM calls

3. Application-specific GUI for easy human auditing

4. Flexible autonomy levels

By studying successful applications like Cursor, we can derive best practices for designing LLM-powered tools that enhance productivity without compromising on AI safety.

Human-AI Collaboration Loops is Super Important

Speeding Up the Verification Process

To truly leverage the power of LLMs, we need to optimize the human-AI collaboration loop. Karpathy emphasizes two key aspects:

1. Speeding up verification through effective GUIs

2. Keeping AI "on a leash" to prevent overwhelming the human collaborator

Lessons from Tesla's Autopilot Development

Karpathy shares insights from his experience with Tesla's Autopilot:

"We did more and more autonomous tasks for the user, and maybe the story that I wanted to tell very briefly is actually the first time I drove a self-driving vehicle was in 2013... This drive was perfect. There were zero interventions, and this was 2013, which is now 12 years ago."

This anecdote illustrates the long journey from impressive demos to real-world deployment, highlighting the need for patience and rigorous testing in AI development.

Democratizing Programming in the AI Era

Everyone Is Now a Programmer

The advent of natural language programming through LLMs has democratized software development. Karpathy coins the term "vibe coding" to describe this phenomenon:

"Suddenly, everyone is a programmer because everyone speaks natural language like English. This is extremely bullish and very interesting to me and also completely unprecedented."

Building a Custom iOS App Without Swift Knowledge

Karpathy shares his experience of creating an iOS app using vibe coding:

"I built this iOS app, and I don't actually know how to program in Swift, but I was really shocked that I was able to build like a super basic app... This was just like a day of work, and this was running on my phone like later that day."

This example demonstrates the transformative potential of LLM-assisted programming, but it also raises questions about job security for traditional developers and the need for new skills in the AI era.

Building for Agents: Creating Future-Ready Digital Infrastructure

Making Our Digital World LLM-Friendly

As LLMs become more prevalent, we need to adapt our digital infrastructure to be more "LLM-friendly." Karpathy suggests several approaches:

Read more

But doing so effectively—and in a way that suits your preferences…

We're bombarded with news from countless sources, often cluttered with ads and irrelevant content. As media theorist Clay Shirky points out,

But what if there was a way to curate your news experience, tailoring it to your interests and delivering it through a familiar, conversational interface? Check out Newsmate – a new telegram bot we built that combines the convenience of messaging apps with the intelligence of AI to bring you personalized news updates.

In our latest videos, we'll walk you through the process of building your own AI-powered Telegram newsbot, complete with code snippets and expert insights.

The Promise of AI-Powered News Curation

Nobel laureate and a pioneer in economics and tech, Herbert A. Simon says:

"In an information-rich world, the wealth of information means a dearth of something else: a scarcity of whatever it is that information consumes. What information consumes is rather obvious: it consumes the attention of its recipients. Hence, a wealth of information creates a poverty of attention."

Imagine waking up to a curated digest of the day's most important stories, tailored to your interests, delivered right to your messenger app. No ads, no fluff – just the news you care about, when you want it. This is the promise of our AI Telegram Newsbot.

If you want to get your “attention” and valuable time back - work with us! We specialize in building AI system that’s tailored to your use cases, let us know!

Work with us!

Key Features of Our Newsbot

1. Personalized Categories: Users can select their preferred news categories, ensuring they only receive updates on topics they care about.

2. Multi-Source Aggregation: The bot can fetch news from multiple predefined sources, with the potential for users to add their own.

3. Scheduled Digests: Users can set preferred times to receive news updates, integrating seamlessly into their daily routines.

4. Conversational Interface: The bot uses natural language processing to engage in basic conversations and respond to user queries.

5. Ad-Free Experience: Unlike traditional news apps, our bot delivers content without intrusive advertisements.

Building the Newsbot: A Technical Overview

Architecture and Components

Our newsbot is built on a modular architecture, consisting of several key components:

1. Telegram API Integration: Handles communication between users and our backend via Telegram's platform.

2. FastAPI Backend: Manages incoming messages and orchestrates the bot's responses.

3. Conversation Manager: (Partially implemented) Handles conversation history and context.

4. Personalization Module: Captures and updates user preferences for improved recommendations.

5. Database: Stores news articles, user preferences, and interaction history.

6. Scheduler: Periodically fetches new articles from defined sources.

7. AI Service: Generates natural language responses and assists in content curation.

Key Technologies and Libraries

• Python: The primary programming language for our bot.

• FastAPI: A modern, fast web framework for building APIs with Python.

• SQLite: A lightweight database for storing news articles and user data.

• Newspaper3k: A Python library for extracting and parsing news articles.

• NLTK: Used for natural language processing tasks like keyword extraction.

• LightLLM: An efficient library for integrating large language models.

Intro Session:

Code Walkthrough:

🛠️✨ Happy practicing and happy building! 🚀🌟

Thanks for reading our newsletter. You can follow us here: Angelina Linkedin or Twitter and Mehdi Linkedin or Twitter.

Source of image:
SWR: https://milvus.io/docs/v2.5.x/assets/advanced_rag/sentence_window.png

🌈 Our RAG course: https://maven.com/angelina-yang/mastering-rag-systems-a-hands-on-guide-to-production-ready-ai

 📚 Also if you'd like to learn more about RAG systems, check out our book on the RAG system: You can download for free on the course site:
https://maven.com/angelina-yang/mastering-rag-systems-a-hands-on-guide-to-production-ready-ai

🦄 Any specific contents you wish to learn from us? Sign up here: https://noteforms.com/forms/twosetai-youtube-content-sqezrz

🧰 Our video editing tool is this one!: https://get.descript.com/nf5cum9nj1m8

📽️ Our RAG videos: https://www.youtube.com/@TwoSetAI

📬 Don't miss out on the latest updates - Subscribe to our newsletter:

The MLnotes Newsletter

MLnotes delivers bite-sized content covering diverse aspects of AI and ML, from real-world applications to entrepreneurship and careers in AI. Together, we can foster knowledge sharing and alleviate information anxiety amidst the rapid advancements in AI!

By Mehdi Allahyari

"You could stop a thousand people on the street and ask them what they want in life and no one is going to say, 'I really wish I was more efficient.'" - Cara Smith

Today, founders are racing to create the next groundbreaking product.

But amidst the frenzy of development and feature optimization, many are falling into a dangerous trap: the efficiency obsession.

What surprised me was how often, this focus on productivity gains can be myopic and limiting, moreover, it's potentially fatal for your brand. Here’s what I’ve learned why efficiency alone won't cut it, and how AI founders can craft brands that truly resonate with their audience.

People Buy Feelings, Not Features

When it comes to building a brand that sticks, emotion is your secret weapon. Cara Smith, co-founder of branding agency Smith and Diction, puts it bluntly:

"To me, the main difference between fine copy and good copy is what's the emotion? What's the feeling that's behind it?"

This insight is crucial for AI founders who often get caught up in the technical capabilities of their products.

Consider this:

while your AI might be able to process tasks 10x faster than a human, that fact alone won't make someone fall in love with your brand (Although Garry from YCombinator would say that’s a must have).

People don't wake up in the morning dreaming about being more efficient. They dream about feeling empowered, creative, or connected. Your branding needs to tap into these deeper human desires.

Your Brand Is More Than Just Your Logo, it's How People See You

"Everybody has a brand. Brand is simply how people see you,"

This perspective shift is vital for AI founders who might be tempted to think branding is just about creating a sleek logo or choosing the right color palette.

Your brand encompasses every interaction a person has with your company. It's the tone of your customer service emails, the user experience of your app, and yes, even the efficiency of your AI. But it's also about the emotions you evoke and the stories you tell.

For AI founders, this means considering how your technology makes people feel, not just what it can do.

Crafting a Verbal Identity That Resonates Beyond Efficiency

One of the most powerful tools in your branding arsenal is your verbal identity.

"Verbal identity is once you cross that line between talking to your internal audience or maybe your partners and talking to your external audience, right? So that's what is your website going to say? What's the tone that you use?"

This goes far beyond a catchy tagline. It's about developing a consistent voice and personality that speaks directly to your audience's needs and aspirations.

Take Gamma, an AI-powered presentation tool. Instead of focusing solely on how quickly it can create slides, their branding revolves around the idea of "get your ideas out there."

This speaks to a deeper desire of their target audience – educators and non-designers who have valuable ideas but struggle with the technical aspects of presentation creation.

Developing a strong verbal identity allows you to maintain a consistent voice across all platforms, helping to build trust and recognition with your audience.

For AI companies, this might mean finding ways to humanize complex technology or articulating your ethical stance on AI development.

Moving Beyond Generic AI Aesthetics and Use Design That Tells a Story

"I always just try to make sure that our logos have like a 10% strange thing about them," says Mike Smith, discussing his approach to logo design.

In a sea of generic AI company logos featuring abstract geometric shapes or glowing orbs, this philosophy of intentional uniqueness can set you apart.

Your visual identity should tell a story about who you are and what you stand for. It's not just about looking sleek or futuristic, but what’s the story behind it.

Take the example of Perplexity AI. Their verbal identity focused on the concept of "where knowledge begins," positioning their product not just as an answer machine, but as a gateway to deeper understanding.

As its designer explained:

"Perplexity is now your starting point and then you can click any of those citation links and go anywhere you want to go."

And that’s why their logo is a spinning door visually represents their mission of opening doors to knowledge.

For AI founders, this might mean moving beyond cliché tech imagery and finding visual metaphors that represent the unique value your AI brings to users' lives.

"As long as the logo can kind of tell a story and like convey an emotion or convey a strategy or something like that, that's when we know we're on to something."

Understanding Your Audience: The Key to Authentic Connection

Creating a brand that resonates requires a deep understanding of your audience. This goes beyond basic demographics. You need to get inside their heads, understand their daily lives, their aspirations, and their pain points.

"The more time you just really spend treating your audience like almost like you're in a novel or you're in a movie and you're putting yourself in the shoes of that character, then that allows you to really think, okay, how do I talk to them in a way that's going to matter to them, not necessarily matter to me."

We talked about the observation of focusing too much on efficiency being a common pitfall for AI founders. As Cara puts it,

"I see a ton of ads, especially in the AI space, that are all about efficiency and I just think it's ridiculous,"

Therefore, instead of focusing solely on how your AI can make processes more efficient, ask yourself these critical questions:

Read more

As much as we don’t want to believe that AI is impacting us,

it is.

I’m floored with what Jerry said and in the meantime not so surprised.

This year to next year, the question on our mind should be:

“Is my career AI-ready?”

To answer this, we turn to Jerry Wang, a visionary in the AI-powered hiring space, for his invaluable insights on the future of work.

"Maybe in the future, everyone is a product manager. You can use the AI copilot to develop a small demo pretty fast. You don't have to code at all. You only have to tell what you want,"

predicts Jerry Wang, CTO of OpenJobs AI.

The Convergence of Software Engineering and AI is Creating Hybrid Roles

Software engineering and AI (just a little more than 2 years ago, more would call this ML or deep learning) don’t exist in separate silos anymore.

Wang observes a fascinating trend:

"What I'm observing is that it isn't a complete replacement of traditional software engineer roles with AI roles, but it is a kind of fusion of skill sets."

This fusion is giving rise to a new breed of professionals - hybrid talents who can seamlessly navigate both traditional software engineering and AI domains.

Companies are increasingly seeking these versatile individuals who can wear multiple hats.

But what does this mean for you?

It's time to expand your skillset.

If you're a software engineer, start familiarizing yourself with AI concepts. If you're an AI specialist, brush up on your software engineering fundamentals. The future belongs to those who can bridge these worlds.

AI Literacy is Becoming a Non-Negotiable Skill Across Industries

"More positions, regardless of the software engineer positions, I mean the other like tech-related positions will require more knowledge about AI," Wang predicts.

This isn't limited to tech roles either. Even traditional industries like healthcare and finance are jumping on the AI bandwagon.

Wang emphasizes,

"Even if you are a product engineer or manager, you have to know more knowledge about AI than today's."

The message is clear:

AI literacy is no longer a nice-to-have, it's becoming a must-have across the board.

For non-technical professionals, don't panic.

You don't need to become an AI expert overnight. Wang suggests starting with the basics:

"They can learn some basic things. They only have to know some concepts and they can watch some channels like your TwoSetAI. They can go to YouTube to find some very fundamental and very easy to follow channels to learn some basic concepts."

The Rise of End-to-End AI Engineers: A New Breed of Unicorns

As AI becomes more integrated into every aspect of product development, there's a growing demand for what Wang calls "end-to-end AI engineers."

These are professionals who can handle everything from data analysis to AI training and deployment.

"I think the job market is expecting more of this kind of roles, who can do like data analysis and AI training and AI deployment," Wang notes. "Those people are pretty welcome in the job market now. And the public salary for those is also very promising."

How promising?

Wang suggests that in Silicon Valley, these roles could command salaries of up to $$$$ per month. However, he cautions that these talents are "very rare." If you're looking to future-proof your career, developing this end-to-end skillset could be your golden ticket.

The Unexpected Skills That Will Set You Apart in the AI Era

While technical skills are crucial, Wang emphasizes two often-overlooked areas that can significantly boost your marketability:

…

Curious to learn more?

In this video, we also covered -

↳ What’s the optimal balance of AI vs. software experience on your dev team?
↳ Which jobs are most at risk, and which new roles are emerging?
↳ How should you upskill today to stay ahead?
↳ Is domain knowledge the new “must-have” for AI-driven development?
↳ Should you master Retrieval-Augmented Generation, multimodal pipelines, vision models, or something else?
↳ What’s the current market rate for a full-stack AI engineer?

Watch the full episode here! 🤓:

👇

Before we go on…a quick announcement -

🚀 Join Our New YouTube Membership Community!

For many of you following us on YouTube. thank you so much for your support! 🦄

In addition to our regular updates, I’m excited to announce the launch of our membership community! Whether you’re looking to master Retrieval-Augmented Generation (RAG), AI Agents, or dive deep into advanced AI projects and tutorials through AI Unbound, there’s something for everyone passionate about AI.

By joining, you’ll gain exclusive content, stay ahead of the curve, and reduce AI FOMO while building real-world skills. Ready to take your AI journey to the next level?

👉 Join the Community Here

Let’s build, learn, and innovate together!

🛠️✨ Happy practicing and happy building! 🚀🌟

Thanks for reading our newsletter. You can follow us here: Angelina Linkedin or Twitter and Mehdi Linkedin or Twitter.

🌈 Our RAG course: https://maven.com/angelina-yang/mastering-rag-systems-a-hands-on-guide-to-production-ready-ai

 📚 Also if you'd like to learn more about RAG systems, check out our book on the RAG system: You can download for free on the course site:
https://maven.com/angelina-yang/mastering-rag-systems-a-hands-on-guide-to-production-ready-ai

🦄 Any specific contents you wish to learn from us? Sign up here: https://noteforms.com/forms/twosetai-youtube-content-sqezrz

🧰 Our video editing tool is this one!: https://get.descript.com/nf5cum9nj1m8

📽️ Our RAG videos: https://www.youtube.com/@TwoSetAI

📬 Don't miss out on the latest updates - Subscribe to our newsletter:

The MLnotes Newsletter

MLnotes delivers bite-sized content covering diverse aspects of AI and ML, from real-world applications to entrepreneurship and careers in AI. Together, we can foster knowledge sharing and alleviate information anxiety amidst the rapid advancements in AI!

By Mehdi Allahyari

Gone are the days when AI companies could simply charge by the token or API call. The market is maturing, and with it, the expectations of customers are evolving.

As Manny Medina, founder of Paid, puts it:

“if it does work, it is up to the AI agent builder and creator to go back to the same customer and say, 'Let's align on things that are important to you and charge for it.'"

This statement encapsulates the core of what’s happening in pricing for AI products: a move from charging for inputs to charging for outcomes.

But why is this shift happening, and what does it mean for the AI ecosystem?

The Four Pillars of AI Pricing: A New Framework for Value

There are four main approaches to pricing that are currently working in the AI space:

1. Activity-based pricing

2. Workflow-based pricing

3. Outcome-based pricing

4. Agent-based pricing

Each of these approaches represents a step towards more sophisticated, value-aligned pricing models. Let's break them down:

Activity-Based Pricing: The Starting Point

Activity-based pricing is the most straightforward approach. It's essentially a credit consumption model where customers pay for the specific actions or computations performed by the AI. While this model is easy to understand and implement, it's also the most vulnerable to commoditization.

Medina warns:

"If you stay there somebody will come along and say I'll do the same thing for cheaper. Yeah. And then you are in a nightmare scenario in which there is tons of others who look just like you."

Workflow-Based Pricing: Stepping Towards Value

Workflow-based pricing involves charging for a series of connected activities that deliver a specific result.

This model begins to align pricing with the value delivered to the customer. As Medina explains:

"When you string a number of activities and you say this workflow is cost this much, like a document review, right? Because then you can separate documents that are small from documents that are long and complicated because they have different consumption patterns and it feels like you're getting closer to value based pricing as opposed to costbased pricing."

Outcome-Based Pricing: Aligning Incentives

Outcome-based pricing is where things get really interesting. Instead of charging for the work done, companies charge based on the results achieved. This could be in the form of a bonus for reaching certain performance metrics or a fee structure tied directly to customer outcomes.

Medina suggests an innovative approach:

"What I I've been recommending to my customer, it's not out there yet, but I'm going to give it a push, is to charge instead of charging per outcome, get an outcome bonus."

This model creates a powerful alignment between the AI provider and the customer, ensuring that both parties are invested in achieving meaningful results.

Agent-Based Pricing: The Future of AI Workforce

Agent-based pricing is perhaps the most forward-thinking model.

It involves charging for AI agents as if they were human employees, based on the work they perform and the outcomes they achieve.

Medina elaborates:

"You can pay instead of saying a platform fee say like you know I'm going to deploy x many agents the agent is going to do this amount of work that is equivalent of a $90,000 a year uh sr I'm going to charge you 20,000 per agent the agent is going to deliver this much work and you can pay me a bonus for the number of meetings booked."

This approach allows AI companies to tap into HR budgets rather than competing for limited software budgets, potentially opening up larger revenue streams.

Lack of visibility into unit economics is a ticking time bomb for many AI startups. Why?

Read more

This week, we’ll explore another set of techniques that includes retriever, generator, and general pipeline enhancement.

Why Your AI Might Be Suffering from "Middle Child Syndrome"

Remember yourself (at least for me 😜) as a student in a crowded classroom. We are usually attentive at the beginning of the lesson and perk up again at the end, but everything in the middle? It's a blur to our memory. This phenomenon, known as the "lost in the middle" problem, is a real challenge for Large Language Models (LLMs) - just like for us! As Mehdi explains:

"LLMs usually pay attention to the beginning and end of the context. So they do not pay as much attention to the middle of this context."

This insight is crucial because it highlights a fundamental flaw in how traditional RAG systems process information. But there are ways to mitigate this so that you can ensure your AI catches every important detail, no matter where it's placed.

Sentence Window Retrieval: Giving Your AI Perfect Vision

One of the advanced techniques this week is sentence window retrieval. Think of this as giving your AI a pair of adjustable binoculars. Instead of focusing on a single chunk of text, it can now look at the surrounding context, capturing a more comprehensive view of the information.

This technique allows the system to:

• Look at chunks before and after the most relevant one

• Adjust the "window size" to include more or less context as needed

• Provide a more nuanced understanding of the information

By implementing sentence window retrieval, you're essentially teaching your AI to read between the lines, capturing subtleties that might otherwise be missed.

Curious to learn more?

In the following video, we also covered -

• Sentence Window Retrieval

• Meta-data Filtering

• Compressing the LLM Prompt

• Adjust chunks sorting in prompt

• Self Reflection

• Query Routing

Watch the full episode here! 🤓:

👇

Before we go on…a quick announcement -

🚀 Join Our New YouTube Membership Community!

For many of you following us on YouTube. thank you so much for your support! 🦄

In addition to our regular updates, I’m excited to announce the launch of our membership community! Whether you’re looking to master Retrieval-Augmented Generation (RAG), AI Agents, or dive deep into advanced AI projects and tutorials through AI Unbound, there’s something for everyone passionate about AI.

By joining, you’ll gain exclusive content, stay ahead of the curve, and reduce AI FOMO while building real-world skills. Ready to take your AI journey to the next level?

👉 Join the Community Here

Let’s build, learn, and innovate together!

🛠️✨ Happy practicing and happy building! 🚀🌟

Thanks for reading our newsletter. You can follow us here: Angelina Linkedin or Twitter and Mehdi Linkedin or Twitter.

Source of image:
SWR: https://milvus.io/docs/v2.5.x/assets/advanced_rag/sentence_window.png

🌈 Our RAG course: https://maven.com/angelina-yang/mastering-rag-systems-a-hands-on-guide-to-production-ready-ai

 📚 Also if you'd like to learn more about RAG systems, check out our book on the RAG system: You can download for free on the course site:
https://maven.com/angelina-yang/mastering-rag-systems-a-hands-on-guide-to-production-ready-ai

🦄 Any specific contents you wish to learn from us? Sign up here: https://noteforms.com/forms/twosetai-youtube-content-sqezrz

🧰 Our video editing tool is this one!: https://get.descript.com/nf5cum9nj1m8

📽️ Our RAG videos: https://www.youtube.com/@TwoSetAI

📬 Don't miss out on the latest updates - Subscribe to our newsletter:

The MLnotes Newsletter

MLnotes delivers bite-sized content covering diverse aspects of AI and ML, from real-world applications to entrepreneurship and careers in AI. Together, we can foster knowledge sharing and alleviate information anxiety amidst the rapid advancements in AI!

By Mehdi Allahyari

It’s probably my favorite definition of creativity — simple, profound, and surprisingly relevant today.

At countless AI events I’ve attended, one question always comes up:

“Will AI replace us?”

My answer has always been: “No. AI will make us all creators.”

But recently, after reading into researches on AI’s impact on human creativity, and seeing firsthand how people are actually using these tools, I’ve started to rethink not just what creativity means, but how we can outgrow the older versions of ourselves with AI, instead of fearing being replaced by it.

In a world shaped more and more by artificial intelligence, it’s never been more important, (or more inspiring) to learn how to collaborate with AI, and to use it wisely as we move into the future.

The Churchill Conundrum: From Bathtub Brilliance to AI Assistance

Imagine Winston Churchill, lounging in his bathtub, dictating a national address to his assistant in the next room. He shouts corrections and refinements, pushing beyond his initial thoughts to craft a message that will resonate with the nation. This scene, immortalized in Albert Finney's portrayal, represents a level of creative collaboration that was once reserved for the privileged few.

Fast forward to today, and we find ourselves in a world where, as Jeremy Utley, adjunct professor of creativity and AI at Stanford University, puts it, "the poorest villager in Palo Alto can have what only Winston Churchill used to have." We now have AI assistants that can understand our context, voice, and intent, ready to collaborate with us in our creative endeavors.

How should we treat AI, a Tool or …?

As we embrace this new era of AI-assisted creativity, we face a crucial decision:

This choice can dramatically impact our creative output and productivity.

Why Treating AI as a Tool Limits Your Creative Potential

Research conducted revealed a surprising finding: while AI can make people 25% faster, 12% more productive, and improve work quality by 40%, less than 10% of professionals are actually reaping these benefits.

In many cases, AI made people less creative. Why?

What’s your guess of the results from the above experiment?

Read more

Artificial intelligence is evolving at a breakneck pace. Every week seems to bring breathless announcements of new AI breakthroughs and capabilities. Amid this frenzy, agentic AI - autonomous software agents that can orchestrate complex tasks - has emerged as the next frontier.

But while the potential of agentic AI is immense, the reality for most enterprises is far more sobering. Despite the hype, true agentic AI remains years away for all but the most advanced organisations.

As Dave Vellante of theCUBE Research puts it,

"2025 is not going to be the year of the agent. It'll be the year of agent marketing."

Enterprises are leaning in, but it's still early days for AI adoption

Recent survey data from ETR paints a picture of cautious but growing enterprise AI adoption:

• 80% of enterprises are now paying for AI in some form

• Nearly two-thirds are tapping into AI APIs

• 39% are experimenting with open-source models

• 27% are training proprietary models on-premises

These numbers show enterprises aren't sitting on their hands when it comes to AI. But they're a far cry from the agentic vision being hyped by many vendors.

The AI infrastructure boom is real, but it's a tale of two speeds

Make no mistake - AI is driving massive infrastructure investment. As Dave Vellante notes in his recent analysis:

"The data center super cycle kicked in in earnest in 2024. What was essentially a perpetually roughly $200 billion business...exploded in 2024...to 350 billion. That's a 58% growth rate in a single year, which is going to continue at an accelerated pace for a decade."

But this boom is playing out very differently for cloud providers versus traditional enterprises:

• Cloud titans like AWS, Google, Microsoft and Meta are pouring over $300 billion into AI data centers this year alone

• On-premises enterprise AI spending is growing, but at a much slower pace

This bifurcation means cloud AI adoption is rocketing ahead, while on-premises enterprise AI won't reach "escape velocity" until later this decade.

2025 is the year of agent marketing, not agent reality

Why? Because the vast majority of enterprises still lack the foundational capabilities needed to effectively deploy and manage autonomous AI agents:

"Our research shows that more than 85% of enterprises still need major upgrades in data quality, and the other 15% probably don't know that they do," says Vellante.

The harsh reality is that most companies are still grappling with basic data management issues. As one example shared by the researchers, "one bank found 6,000 table entries that defined what a customer was." If you can't even agree on what constitutes a customer, how can you possibly expect AI agents to make accurate, business-critical decisions?

As Vellante warns,

"agents hallucinate when the ground truth is fuzzy."

In other words, garbage in, garbage out – but now with potentially catastrophic consequences as AI agents act on flawed information.

This doesn't mean AI won't deliver value in the near-term. Co-pilots and other assistive AI will drive real productivity gains. But the grand vision of fully autonomous agents orchestrating complex business processes? That's still years away for most.

There are three critical areas where enterprises are falling short in their readiness for agentic AI:

1. Data quality and lineage remain massive hurdles

AI agents need high-quality, well-structured data to function effectively. But most enterprises are drowning in data silos and inconsistencies.

2. Integration and orchestration are far from seamless

Vendors love to tout "seamless integration" for their AI solutions. The reality is far messier. Decades of patchwork enterprise integration efforts have left a tangled web that autonomous agents can't easily navigate.

Some SaaS vendors are making progress within their own domains. But cross-application integration remains a major challenge. The risk is ending up with siloed AI agents that can't effectively collaborate across business functions.

What’s even more important but very few vendors factor it in their plan is…

Read more

Are you tired of AI giving you half-baked answers? Frustrated with language models that seem to know everything but your specific data?

You're not alone. While Retrieval Augmented Generation (RAG) promised to bridge the gap between AI and your proprietary information, many are finding that vanilla RAG just isn't cutting it. The good news is that there are many advanced techniques that can help us get better results!

But before we expose those limitations and show you how to overcome them, let's make sure we're all on the same page.

What is RAG, and Why Should You Care?

RAG, or Retrieval Augmented Generation, is a game-changing technique that connects external data sources to Large Language Models (LLMs). It allows you to ask questions about your own proprietary data and get informed responses. In its simplest form, vanilla RAG works by chunking your documents, embedding them, storing them in a vector database, and then retrieving relevant chunks when a user asks a question.

But remember: vanilla RAG is just the tip of the iceberg. Researchers have introduced different types of RAG improvement techniques that here we are going to cover a few of them.

Vanilla RAG is Holding You Back: Here's Why You Need to Level Up

While vanilla RAG is a great starting point, it falls short in several key areas. For instance, "When your question is let's say so-called summarization type questions... or when there is a comparison you want to just compare multiple things against each other... vanilla RAG fails to answer them."

This limitation is just one of many reasons why you need to explore advanced RAG techniques.

Create Fake Questions to Get Real Answers: The Magic of Hypothetical Prompts

One interesting approach is the use of hypothetical questions. Instead of directly passing a user's query to the vector database, this method generates several relevant questions first.

For instance, "We can generate some hypothetical questions that users may ask in the future and later on when user ask a question we can go and find the most similar hypothetical questions that we have then find the relevant chunks."

This approach allows for a more nuanced search, potentially uncovering information that a direct query might miss.

Fake It Till You Make It: Hypothetical Document Embeddings

Taking the concept of "fake it till you make it" to a whole new level, hypothetical document embeddings involve generating fake responses to a user's query without any context. In our video today, Mehdi explained:

"We can generate some fake documents... Now that we have this fake document then we can go and pass this document and find relevant chunks from the vector database that are similar or related to this fake document."

This technique can help bridge the gap between the user's query language and the language used in your documents, potentially leading to more relevant retrievals.

Curious to learn more?

In the following video, we also covered -

• step-back prompting,

• sub-queries,

• automatic chunk merging,

• hierarchical indexing and

• hybrid retrieval and reranking…

Watch the full episode here! 🤓:

👇

Before we go on…a quick announcement -

🚀 Join Our New YouTube Membership Community!

For many of you following us on YouTube. thank you so much for your support! 🦄

In addition to our regular updates, I’m excited to announce the launch of our membership community! Whether you’re looking to master Retrieval-Augmented Generation (RAG), AI Agents, or dive deep into advanced AI projects and tutorials through AI Unbound, there’s something for everyone passionate about AI.

By joining, you’ll gain exclusive content, stay ahead of the curve, and reduce AI FOMO while building real-world skills. Ready to take your AI journey to the next level?

👉 Join the Community Here

Let’s build, learn, and innovate together!

🛠️✨ Happy practicing and happy building! 🚀🌟

Thanks for reading our newsletter. You can follow us here: Angelina Linkedin or Twitter and Mehdi Linkedin or Twitter.

Source of image:
HQ: https://milvus.io/docs/v2.5.x/assets/advanced_rag/hypothetical_question.png

HyDE: https://milvus.io/docs/v2.5.x/assets/advanced_rag/hierarchical_index.png

🌈 Our RAG course: https://maven.com/angelina-yang/mastering-rag-systems-a-hands-on-guide-to-production-ready-ai

 📚 Also if you'd like to learn more about RAG systems, check out our book on the RAG system: You can download for free on the course site:
https://maven.com/angelina-yang/mastering-rag-systems-a-hands-on-guide-to-production-ready-ai

🦄 Any specific contents you wish to learn from us? Sign up here: https://noteforms.com/forms/twosetai-youtube-content-sqezrz

🧰 Our video editing tool is this one!: https://get.descript.com/nf5cum9nj1m8

📽️ Our RAG videos: https://www.youtube.com/@TwoSetAI

📬 Don't miss out on the latest updates - Subscribe to our newsletter:

The MLnotes Newsletter

MLnotes delivers bite-sized content covering diverse aspects of AI and ML, from real-world applications to entrepreneurship and careers in AI. Together, we can foster knowledge sharing and alleviate information anxiety amidst the rapid advancements in AI!

By Mehdi Allahyari

Founders are racing to create the next groundbreaking AI demo that will make investors' jaws drop and wallets open.

But here's the cold, hard truth:

Rebecca Lynn, founder and managing partner of Canvas Ventures, pulls no punches when it comes to what venture capitalists are really looking for in AI startups.

And, perhaps a bit surprisingly, it's not just about how impressive your demo looks in a controlled environment.

Your AI demo wowed investors, but here's why they're still not writing checks!

"It's really easy to create a company in Gen AI in demo mode,"

Lynn explains.

"It is a very different thing to take that beautiful demo and put it in the wild and scale it."

This gap between a polished demo and a scalable, real-world product is where many AI startups stumble and fall. Lynn has seen it happen time and time again:

"We've already seen a handful of companies that were backed by amazing investors kind of blow up because they weren't able to transition from that really cool slick demo into the wild, essentially into full production."

So, what's a founder to do? Lynn's advice is crystal clear:

Forget first-mover advantage: Why being second could make you millions

In a world obsessed with being first, Lynn shared different opinions that might just change how you think about your startup strategy.

"I think first mover advantage is a fallacy," she states boldly.

Why?

Because being first often means spending enormous amounts of time and money to prove out a brand new market. And once you've done that hard work? You're left with a mountain of technical debt.

Lynn's investment in Lending Club, which went on to become the largest US tech IPO in 2014, wasn't a first-mover play. Prosper had already seeded the market. But Lending Club, as a second mover, was able to learn from Prosper's experience and quickly develop a better product with better marketing and no technical debt.

"I would challenge anyone to come up with more than just a handful of companies that are public today that truly were the first mover," Lynn says. "There are very few."

The counterintuitive trait that makes CEOs irresistible to both customers and investors

When it comes to what makes a CEO truly stand out, Lynn's answer might surprise you. It's not about having the most cutting-edge technology or the most impressive pedigree.

It's about -

Read more

It’s harder to find a chef on standby around the clock, but an executive assistant who can handle everything around your calendar and itinerary - AI is ready to do just that!

We've built an AI-powered calendar assistant…

Read more

I ran into a16z’s briefing on 11x’s story, let’s see what we can learn from the 11x saga as startups, investors, and customers alike.

Their Meteoric Rise is Too Good to Be True?

11x burst onto the scene in 2022 with a bold promise: to revolutionize outbound sales through AI-powered bots.

Founded by Hasan Sukkar, the company claimed to have reached nearly $10 million in annualized recurring revenue (ARR) within just two years. This explosive growth caught the attention of heavyweight investors, with Benchmark leading a $24 million Series A round and Andreessen Horowitz (a16z) following up with a $50 million Series B.

On the surface, 11x seemed to have it all – cutting-edge technology, rapid growth, and the backing of Silicon Valley's most prestigious venture capital firms. But as we'll soon discover, appearances can be deceiving.

Red Flags Waving in the Silicon Valley Breeze

"Our logo is on their website, but we're not a customer"

One of the first red flags to emerge was 11x's questionable use of customer logos on its website. Multiple companies, including ZoomInfo and Airtable, found their logos displayed without permission. ZoomInfo's spokesperson didn't mince words:

"We did not give them permission to use our logo in any manner, and we are not a customer."

This wasn't just a simple oversight. ZoomInfo had conducted a short trial of 11x's product, found it "performed significantly worse than our SDR employees," and decided not to move forward. Yet, 11x continued to claim ZoomInfo as a customer for months, even in sales calls and on its AI dialer.

Airtable faced a similar situation, with 11x listing them as a customer on their "manifesto" page long after a brief, unsuccessful trial. These weren't isolated incidents – another unnamed company shared a comparable experience.

The ARR Mirage: When Numbers Don't Add Up

11x's reported ARR figures began to raise eyebrows among employees and industry insiders. The company's approach to calculating ARR was, to put it mildly, creative. Here's how it worked:

1. 11x insisted on one-year contracts for pilot programs.

2. These contracts included a "break clause" at three months, essentially creating a trial period.

3. When reporting ARR, 11x counted the full year's value – even for customers who used the break clause to end their trial.

A former employee laid it out starkly:

"We were losing 70-80% of customers that came through the door."

Yet, 11x's reported ARR didn't reflect this reality. Another ex-employee added,

"They absolutely massaged the numbers internally when it came to growth and churn."

While 11x claims to use "contracted ARR (CARR)" and says investors were aware of this metric, the discrepancy between reported figures and actual long-term customer value was significant. One employee estimated that out of a reported $14 million ARR, only about $3 million came from contracts that survived beyond the three-month trial period.

When Reality Catches Up

Product Promises vs. Performance just don’t Match!

As customers began using 11x's AI-powered sales tools, a gap emerged between expectations and reality. Many companies canceled after their trial periods, citing various issues:

• Unrealistic expectations: Some customers hoped 11x could replace entire outbound sales teams, a promise that proved too good to be true.

• Underwhelming results: The actual number of meetings, demos, and calls booked fell short of projections.

• Technical issues: Customers reported the product hallucinating or failing to load altogether.

• Manual intervention: Instead of automating tasks, customers often had to manually check and correct the AI's work.

One reviewer on Medium didn't hold back, stating that 11x's product was "far less effective and yet cost more than its competitors." A former engineer was even more blunt: "The products barely work."

The Human Cost: A Toxic Work Culture Emerges

Behind the scenes, 11x's work environment was taking a toll on its employees. Multiple sources described a culture of overwork and constant pressure:

• 60+ hour work weeks were the norm

• Employees were expected to be available at all hours

• Weekend and holiday work was common

• Public shaming on Slack for unavailability or mistakes

• Threats of dismissal for speaking out

One current employee said:

"There's a lot more under the hood. One day, there will be a documentary about this guy. I do believe that's how scandalous he is."

Lessons for Startups: Building on Solid Foundations🦄 (Lessons for investors below!👇 )

The 11x saga offers several crucial lessons for aspiring entrepreneurs and startup founders:

Read more

A recent viral concept - MCP, could be the unsung hero that's about to change everything in the world of AI. But what exactly is MCP, and why should you care?

What the Heck is MCP Anyway?

MCP, or Multimodal Conversational Protocol, is the latest buzzword taking the AI world by storm. But don't let the fancy name fool you – at its core, MCP is a brilliantly simple solution to a complex problem.

Professor Ross Mike, explains it best:

"Understanding MCP is really important, but you'll also realize the benefits and why it's sort of a big deal, but not really at the same time."

In essence, MCP is a new standard that allows LLMs (like ChatGPT) to seamlessly connect with external tools and services. Think of it as a universal translator that enables your AI assistant to speak fluently with databases, APIs, and a whole host of other digital services.

Current LLMs Are Like Brilliant Scholars Trapped in a Library.

To truly appreciate the significance of MCP, we need to understand the limitations of current LLMs. As Professor Mike points out:

"LLMs by themselves are incapable of doing anything meaningful. What do I mean by that? If you remember the first ChatGPT 3 or 3.5, if you just open any chatbot and tell it to send you an email, it won't know how to do that."

Imagine the smartest person you know, locked in a vast library with all the world's knowledge. They can answer questions and discuss any topic, but they can't actually do anything beyond the confines of that library. That's essentially what we're dealing with when it comes to current LLMs.

We Need to Move From Basic LLMs to Tool-Connected Assistants

The next step in AI assistant evolution was connecting LLMs to external tools. This allowed them to perform more practical tasks, like searching the internet or updating spreadsheets. However, this approach came with its own set of headaches.

Professor Mike illustrates the problem:

"You start to become someone who glues a bunch of different tools to these LLMs, and it can get very frustrating, very cumbersome. If you're wondering why we don't have an Iron Man level Jarvis assistant, it's because combining these tools, making it work with the LLM is one thing, but then stacking these tools on top of each other, making it cohesive, making it work together is a nightmare itself."

MCP Lets All Your Agentic Tools Speak the Same Language

This is where MCP comes in to save the day. Instead of dealing with a mishmash of different tools and APIs, each speaking its own "language," MCP acts as a universal translator.

Professor Mike breaks it down with a brilliant analogy:

"Think of every tool that I have to connect to to make my LLM valuable as a different language. Tool one's English, tool two is Spanish, tool three is Japanese, right? MCP you can consider it to be a layer between your LLM and the services and the tools, and this layer translates all those different languages into a unified language that makes complete sense to the LLM."

A Peek Under the Hood of How MCP Is Structured

To truly grasp the power of MCP, it's helpful to understand its basic structure. The MCP ecosystem consists of four main components:

1. MCP Client: This is the user-facing side, where the LLM interacts.

2. MCP Protocol: The standardized communication method between client and server.

3. MCP Server: Translates the capabilities of external services for the client.

4. External Service: The actual tool or API being accessed.

What Do MCPs Look Like?

1) A Simple JSON-Based MCP Payload

Imagine you have a user querying a corporate knowledge base for recent product updates. MCP could define a JSON structure for how this conversation flow is packaged:

Explanation:

• The protocol_version allows for backward compatibility.

• context_retrieval details the sources for relevant documents.

• context_wrapping compresses or summarizes those documents under wrapped_context.

• prompt_assembly merges the user’s question with the curated context.

• model_coordination tells the system which model to call and what format we want back.

2) A Multi-Step Chat Example

Consider an interactive chatbot that helps users analyze legal documents. MCP can define how each turn of the conversation is handled:

Read more

Imagine waking up in 2025 to find that your job as a software engineer has been completely transformed. The code you once painstakingly wrote line by line is now generated in seconds by AI. The architecture decisions you agonized over are now suggested by intelligent systems. And the deployment processes you met…

Read more

Dr. Fei-Fei Li, a name synonymous with pioneering AI research and the person behind ImageNet, a dataset that revolutionized computer vision and catalyzed the deep learning boom. In a recent conversation with Brad Smith on the "Tools and Weapons" podcast, Li revealed a surprising truth about the core of innovation:

"Curiosity is not just moments of delight, or sense of wonder. Curiosity is a state of being, and that state of being makes me happy."

This statement isn't just a feel-good platitude. It's a powerful insight into the engine that drives scientific progress. But how does one cultivate and maintain this curiosity in a field as complex and rapidly evolving as AI? Let's dive deeper into Li's journey and uncover the lessons that could reshape how we approach innovation.

Could the next big AI breakthrough be inspired by an observation at a local flea market or a casual conversation with a stranger?

Picture this: A teenage girl, newly immigrated to the United States, spending her weekends at yard sales with her father. It doesn't sound like the origin story of a world-renowned AI scientist, does it? But for Fei-Fei Li, these seemingly mundane experiences were formative in shaping her approach to science.

Li recounts how her father approached each yard sale with childlike wonder:

"He would approach every little like stand, or table of whatever items with that kind of pure child-like, 'Oh my God, Fei-Fei, come and look at this cup. It has a owl on it', or 'Look at this garden tool. I've never thought of you can design it this way so that it's easy to uproot a plant.'"

This anecdote is quite charming, and to me it sounds so silly, and yet it is a profound reminder. Li draws a direct parallel between her father's approach to yard sales and the scientific mindset:

"Now that I've been a career scientist for decades, I realize that delight in seeing things for the first time, and keeping that curiosity is the same as what we do as scientists the first time I open a paper, look at the results someone gives us, or heard about a algorithm."

The lesson here is clear:

Curiosity isn't just for labs and research papers. It's a way of engaging with the world that can be practiced and honed in everyday life.

This perspective challenges us to reconsider how we approach our daily experiences.

Could the next big AI breakthrough be inspired by an observation at a local flea market or a casual conversation with a stranger?

As a mom with small kids, this is a reminder to me how important it is to encourage them to explore and be curious, rather than just memorizing what’s taught in the text books.

Especially with the current development of AI, perhaps education in the future will not be bounded by pedigree alone. Comparing to aiming for Ivy Leagues, I would rather my kids build their confidence to pursue what they are curious and passion about in life, and not chasing “the rat race”.🤓

Do you have the courage to say “No” to a Six-Figure Salary?

Imagine standing at a crossroads in your career. On one path, a prestigious consulting firm offers you a six-figure salary – financial security and societal approval. On the other, the uncertain world of academic research, with its long hours, grant applications, and no guarantee of success.

Which would you choose?

Tbh, I probably would chose the consulting offer.

But for Fei-Fei Li, this wasn't a hypothetical scenario. It was a real decision she faced early in her career. The choice was made more difficult by her family's financial struggles and her mother's health issues. Yet, when Li wavered, her mother's advice was clear:

"Go for what you love."

Li reflects on this moment:

"Curiosity is a state of being, and that state of being makes me happy, and being a scientist makes me happy, because I'm entitled to be curious all the time, and my mom knew that, and that's what she encouraged me to do."

This decision point highlights a crucial aspect of innovation that's often overlooked:

It's a reminder that breakthrough ideas often come from those willing to take risks and follow their intellectual passions, even when the immediate rewards aren't apparent.

But Li's story isn't just about individual choice. It underscores a broader question:

How can we, as a society, create environments that encourage more people to make this choice?

How can we build systems that value and reward curiosity-driven pursuits?

ImageNet: You can change the world if you are willing to take the risk.

In the early 2000s, when AI was still in its "winter" phase, Fei-Fei Li embarked on a project that many of her colleagues considered misguided at best and career-ending at worst. This project was ImageNet, a dataset of 15 million images across 22,000 categories.

Li describes the skepticism she faced:

"Some of them will say, 'Well, that's kind of a bad idea.' Some of them would even go as far as saying, 'That might be an idea that hurts your career.'"

Yet, Li persisted. Why? Because she saw something others didn't:

"We observed, before we made ImageNet that that's just a wrong way of thinking. Mathematically, these machine learning models need to be able to learn and generalize, and the way to drive that learning and generalization in addition to the architecture of the algorithm, is actually through data, and diverse data, a large amount of data."

This insight – that big, diverse datasets were crucial for machine learning – seems obvious now. But at the time, it was revolutionary. ImageNet became the catalyst for the deep learning revolution, fundamentally changing the landscape of AI research and applications.

The story of ImageNet teaches us several crucial lessons:

1. The power of contrarian thinking: Sometimes, the most impactful ideas are those that go against the current consensus.

2. The importance of persistence: Breakthrough innovations often require pushing through skepticism and setbacks.

3. The value of interdisciplinary insights: Li's background in neuroscience informed her approach to AI, highlighting the importance of diverse perspectives in research.

But perhaps most importantly, it underscores the unpredictable nature of scientific progress.

Who could have foreseen that a massive image dataset would be the key to unlocking the potential of deep learning?

Why academic freedom matters more than ever?

In an era where tech giants dominate headlines with their AI breakthroughs, it's easy to overlook the critical role of academia in driving innovation. Fei-Fei Li's career offers a compelling argument for why academic research remains indispensable.

Li passionately advocates for curiosity-driven research in academia:

"Curiosity based research fundamentally is linked to the word freedom, is that, when you are a researcher or professor in a university in an academic setting, you don't have a manager, or a director who tells you, 'Fei-Fei, come here to Princeton or Stanford, and these are the three things you should work on.' No, you are just given a desk, an office, and an opportunity to apply for funding, and then do whatever you want."

This freedom allows researchers to pursue ideas that might seem impractical or even foolish in the short term but can lead to groundbreaking discoveries. ImageNet is a prime example of this. Had Li been constrained by short-term profit motives or narrow research directives, this project – which fundamentally changed the course of AI – might never have happened.

But academic freedom isn't just about allowing researchers to follow their whims. It's about creating an environment where:

1. Long-term thinking is encouraged: Unlike industry research, which often focuses on quarterly results, academic research can tackle problems with longer time horizons.

2. Failure is acceptable: The freedom to fail is crucial for innovation. In academia, a "failed" experiment can still yield valuable insights.

3. Cross-pollination of ideas occurs: Universities bring together experts from diverse fields, fostering interdisciplinary collaboration that can lead to unexpected breakthroughs.

4. Ethical considerations are prioritized: Academic research can focus on the broader implications of technology without being driven solely by market demands.

However, this academic freedom doesn't exist in a vacuum. It requires support, particularly in the form of funding. Li emphasizes the crucial role of government funding in her career:

"Overall, it's critical. I would say, of course you have to take it down and analyze which project got funding, but as you said, for my early years, absolutely, The National Science Foundation is one of the major funding source."

This brings us to a critical point: The health of our innovation ecosystem depends on continued investment in academic research. As we navigate the rapidly evolving landscape of AI, maintaining and strengthening this support becomes more important than ever.

The Ecosystem of Innovation: Why we need a symphony, NOT a solo

One of the most striking insights from Li's conversation is the importance of what she calls the "ecosystem of innovation."

Read more