Workflow Overview: A Multi-Agent Research Assistant Over 4 Context Sources

The previous topic covered context engineering's conceptual framework (6 types, 4 stages); this topic walks through this course's own full hands-on implementation, applying that framework to a concrete, working system. This course states its goal directly: we'll build a multi-agent research assistant using context engineering principles. This Agent will gather its context across 4 sources: Documents, Memory, Web search, and Arxiv.

The high-level workflow, per this course: a user submits a query; the system fetches context from docs, web, arxiv API, and memory; it passes the aggregated context to an agent for filtering; it passes the filtered context to another agent to generate a response; and it saves the final response to memory. Notice this is a direct, concrete instance of the previous topic's 4 stages: fetching from docs/web/arxiv/memory is Reading; combining them is aggregation; filtering is Compressing; and saving the final response to memory is Writing — the abstract framework made literal.

This course's tech stack names five specific tools, each handling one piece of the pipeline: Tensorlake to get RAG-ready data from complex documents (covered in depth in the next subtopic); Zep for memory (a temporal-knowledge-graph-based memory layer); Firecrawl for web search (fetching and structuring live web content); Milvus for the vector DB (self-hosted, storing the RAG-ready chunks for retrieval); and CrewAI for orchestration (coordinating the multiple agents — a filtering agent and a synthesizing agent — that the workflow uses).

An important caveat this course states explicitly and worth internalizing before diving into the specific steps: this is one of many blueprints to implement a context engineering workflow. Your pipeline will likely vary based on the use case. The specific TOOLS here (Tensorlake, Zep, Firecrawl, Milvus, CrewAI) are one valid combination, not the only correct architecture — what matters more than any specific tool choice is the underlying PATTERN: multiple context SOURCES feeding into an aggregation-then-filtering step, before generation, with results saved back for future use. That pattern is what the remaining three subtopics in this topic walk through in implementation detail.

# The book's high-level workflow, expressed as a runnable pipeline
# skeleton -- fetch from 4 sources, filter, generate, save to memory.
# (The next 3 subtopics fill in each stage's real implementation.)

def fetch_from_docs(query: str) -> list[str]:
    return [f"[doc chunk relevant to: {query}]"]        # via Tensorlake + Milvus

def fetch_from_memory(query: str) -> list[str]:
    return [f"[past interaction relevant to: {query}]"]  # via Zep

def fetch_from_web(query: str) -> list[str]:
    return [f"[web result relevant to: {query}]"]        # via Firecrawl

def fetch_from_arxiv(query: str) -> list[str]:
    return [f"[arxiv paper relevant to: {query}]"]       # via arXiv API

def filter_context(aggregated: list[str], query: str) -> list[str]:
    """The 'context evaluation agent' step -- drops irrelevant items."""
    return [c for c in aggregated if query.lower() in c.lower()]

def generate_response(filtered_context: list[str], query: str) -> str:
    """The 'synthesizer agent' step."""
    return f"Answer to {query!r}, grounded in {len(filtered_context)} context item(s)"

def run_workflow(query: str, memory_store: list[str]) -> str:
    aggregated = (
        fetch_from_docs(query) + fetch_from_memory(query)
        + fetch_from_web(query) + fetch_from_arxiv(query)
    )
    filtered = filter_context(aggregated, query)
    response = generate_response(filtered, query)
    memory_store.append(response)   # "save the final response to memory"
    return response

memory = []
answer = run_workflow("transformer attention", memory)
print(answer)
print("memory after run:", memory)