The Log Is The Agent

1. Nhân vật Skyrim của bạn thật ra là gì?

Ishaan mở đầu bằng lời chào và tự giới thiệu: anh là CEO của Omnara, và chủ đề hôm nay là "the log is the agent", log chính là agent. Ý tưởng cốt lõi của talk rất đơn giản. Phần lớn mọi người nghĩ agent là cái model, hoặc là môi trường thực thi (execution environment) mà nó đang chạy bên trong. Anh cho rằng đó là một abstraction sai. Thứ thật sự tạo nên danh tính (identity) của một agent là log của nó, và cả talk là để chứng minh điều đó.

Slide tiêu đề The Log Is the Agent, Ishaan Sehgal, CEO Omnara (YC S25) — Slide mở đầu: "The Log Is the Agent", Ishaan Sehgal, CEO của Omnara, công ty thuộc batch YC S25 của Y Combinator.

Để dẫn vào, anh nhờ người nghe nghĩ về một nhân vật mà bạn đã chơi 100 giờ trong trò chơi yêu thích của mình, trong ví dụ này là Skyrim. Vậy chính xác thì nhân vật của bạn là gì? Có phải là game engine không? Có phải là cái máy PlayStation không? Có phải là tay cầm không? Không phải. Những thứ đó quan trọng, đó là những thứ bạn tương tác và chúng là thứ "chạy" nhân vật, nhưng không thứ nào trong số đó là nhân vật của bạn.

Slide What is your character? với hình nhân vật Skyrim đang đi trong một ngôi làng — "What is your character?": một nhân vật Skyrim đang đi trên con đường làng. Câu hỏi đặt ra là thứ gì trong cả hệ thống máy, game và tay cầm mới thật sự là nhân vật này.

Nhân vật của bạn là data. Nó là file save. Điều này quan trọng vì nếu cái PlayStation của bạn bốc cháy, nhân vật của bạn không mất đi. Bạn có thể mua một máy PlayStation khác, tải file save từ cloud về, và tiếp tục chơi đúng tại chỗ nhân vật đang đứng. Lý do là toàn bộ agent, tức danh tính, lịch sử và state của nó, đều được ghi lại trong data. Nhân vật sống trong data.

Slide Your character is the save file, hình một chiến binh vung kiếm bên cạnh một khối máy đang vỡ vụn — "Your character is the save file": hình minh hoạ một chiến binh vẫn tiếp tục chiến đấu trong khi cỗ máy bên cạnh vỡ thành từng mảnh. Phần cứng có thể hỏng, nhân vật thì nằm trong file save.

Đây chính là cách nhìn (framing) mà Ishaan muốn mang sang agent.

2. Mọi người đang chỉ nhầm chỗ khi nói về agent

Hôm nay, khi mọi người nói về agent, họ thường chỉ vào sai chỗ. Họ sẽ nói agent là model, hoặc agent là runtime. Như anh đã nói ở trên, những thứ đó có quan trọng, nhưng chúng không phải là agent. Agent là data của nó, và cụ thể hơn, agent là log của nó.

Slide what people think the agent is: model, runtime / sandbox, tools, loop, framework — Những thứ người ta thường gọi là "agent": model, runtime hoặc sandbox, tools, vòng loop, framework. Theo Ishaan, tất cả đều giống game engine, máy chơi game và tay cầm trong ví dụ Skyrim: cần thiết để chạy, nhưng không phải bản thân agent.

Đặt cạnh ví dụ Skyrim, phép so sánh khá rõ: model giống bộ não xử lý, runtime và sandbox giống cái máy, tools giống tay cầm, còn loop và framework giống game engine. Thứ đi theo agent qua mọi lần thay máy, thay model hay thay framework chỉ có một: lịch sử của nó.

3. Log là gì?

Vậy thật ra log là gì? Ở mức đơn giản nhất, log là lịch sử sự kiện (event history) dạng append-only của agent, tức là chỉ được ghi nối thêm vào cuối, không sửa, không xoá. Nó chứa mọi input của user, mọi output của model, mọi tool call, mọi tool result, mọi permission, mọi failure. Ý tưởng là mọi lần chuyển state (state transition) mà agent thực hiện đều được ghi vào log.

Slide What is the log? liệt kê Event History và một chuỗi sự kiện ví dụ — "What is the log?": Event History gồm User Input, Model Input/Output, Permissions, Tool call và tool result. Cột ví dụ bên phải là một chuỗi sự kiện điển hình: user hỏi, model trả lời, một tool được gọi, có permission request, người duyệt, tool trả kết quả, và lượt (turn) hoàn tất.

Điều này quan trọng vì nó có nghĩa là danh tính của agent không bị trói vào runtime, model hay tools. Những thứ đó chỉ đang diễn giải (interpret) log và ghi nối thêm vào log. Chúng đọc log, hành động dựa trên nó, rồi ghi sự kiện tiếp theo trở lại. Và vì thế, chỉ riêng log thôi là đủ để resume agent.

4. Mọi thao tác đều đọc từ log hoặc ghi nối vào log

Một khi bạn định nghĩa agent là log, phần còn lại của hệ thống trở nên dễ suy luận hơn rất nhiều, vì mọi thao tác hoặc là đọc từ log, hoặc là ghi nối vào log. Model đọc từ log rồi quyết định hành động kế tiếp. Tool runner thực thi hành động đó rồi ghi nối kết quả vào log. Tất cả chạy trong một vòng loop. Mọi thứ tự phối hợp với nhau xoay quanh log.

Sơ đồ Every operation reads from or appends to the log: Log, Determine Next Step, Handle Next Step, Append to Log — "Every operation reads from or appends to the log": log đi vào bước Determine Next Step, bước này rẽ ra nhiều hướng xử lý (Handle Next Step, "whatever you want"), và mọi kết quả quay về Append to Log để vòng lặp tiếp tục. Sơ đồ được ghi là chuyển thể từ 12-factor agents của Dex.

Trong thực tế, một vòng loop đơn giản hoá có thể trông như thế này. Bạn dựng lại (reconstruct) state từ log. Bạn đưa state đó cho model. Model đề xuất bước tiếp theo, và bạn ghi nối response đó vào log. Nếu response yêu cầu một tool, bạn chạy tool đó và cũng ghi nối kết quả vào log, rồi lặp lại.

while session_has_work:
    state = reconstruct_from_log(session_id)
    response = model.next(state)
    append(response)

    if response.requests_tool:
        result = run_tool(response.tool_call)
        append(result)

Slide Simplified Loop với đoạn pseudocode while session_has_work — "Simplified Loop": mỗi vòng bắt đầu bằng việc dựng lại state từ log theo session_id, không giữ gì trong bộ nhớ của process giữa các vòng.

Insight quan trọng ở đây không phải là vòng loop này phức tạp. Insight quan trọng là vòng loop này dùng xong là bỏ được (disposable). Một worker có thể nhận (claim) session, đọc log, đẩy agent tiến thêm một bước, ghi kết quả, rồi biến mất hoàn toàn. Điều đó có nghĩa là bất kỳ worker nào khác cũng có thể nhặt session đó lên làm tiếp sau này.

5. Database đã học bài này trước

Pattern này hẳn nghe quen. Database đã phải học bài này trước. Suốt nhiều năm, database trông như những hệ thống không minh bạch, khó suy luận, với table, index và materialized view. Nhưng bên dưới mọi database nghiêm túc là một cái log, và cái log đó là chuỗi thay đổi bền vững (durable sequence of changes). Mọi thứ khác đều là view.

Sơ đồ Databases learned this first: Log ở trên, bên dưới là Tables, Indexes, Caches, Materialized Views, Search, Analytics — "Databases learned this first": Log nằm ở gốc, còn Tables, Indexes, Caches, Materialized Views, Search và Analytics đều được dẫn xuất từ nó. Đây là ý mà Martin Kleppmann từng trình bày trong bài "Turning the database inside-out".

Ishaan cho rằng agent cần đúng cú đảo ngược (inversion) đó. Hôm nay agent được đối xử như những hệ thống phức tạp và mờ đục, nhồi đầy model, prompt và tool call. Nhưng với một session bền vững, log phải là thứ chính (primary). Context được đưa vào model là một projection của log. UI render bên trên là một projection của log. Debugging và traceability là một projection. Auditing là một projection. Compaction cũng là một projection, và anh sẽ nói về nó ngay sau đây. Nhưng bản thân log thì không phải projection. Log là lịch sử bền vững mà mọi projection kia đều có thể sinh ra từ đó.

Áp cách nhìn của database vào agent: log là nguồn duy nhất, còn context gửi cho model, UI, debugging, audit và compaction đều chỉ là projection (khung nét đứt), sinh lại được bất cứ lúc nào từ log.

6. Phản biện thứ nhất: compaction

Có hai phản biện đáng bàn với luận điểm "log là agent", và Ishaan xử lý từng cái một.

Slide Objections — Slide chuyển sang phần "Objections": hai câu hỏi người nghe hay đặt ra cho luận điểm log là agent.

Bắt đầu với compaction. Một cái log có thể dài ra vô hạn, nhưng góc nhìn của model vào log thì không. Context window có giới hạn, nên đến một lúc bạn buộc phải nén (compact) log thành một biểu diễn nhỏ hơn để model có thể suy luận. Nhưng điểm quan trọng là compaction không phải phép màu, và nó không phá vỡ luận điểm rằng log là agent.

Compaction là lossy. Một bản tóm tắt sau compaction sẽ không tái hiện hoàn hảo state của agent ở dạng nhỏ hơn. Nó thật sự vứt bỏ thông tin. Điểm mấu chốt là log đầy đủ mới là bản ghi (record), còn compaction chỉ là một projection của nó, giống như materialized view không phải là database, hay bản tóm tắt của một cuộc trò chuyện không phải là cuộc trò chuyện đó.

Slide Compaction is not the log, hình một khối dữ liệu lớn phát sáng chảy thành một khối lập phương nhỏ — "Compaction is not the log": một khối dữ liệu cao lớn bị dồn lại thành một khối lập phương nhỏ. Khối nhỏ tiện cho context window, nhưng phần thông tin rơi rớt dọc đường thì không lấy lại được từ nó.

Nếu bạn giữ log thô (raw log), bạn luôn có thể sinh ra projection mới từ nó. Nhưng nếu bạn vứt raw log đi và chỉ giữ bản compaction, bạn đã thực sự đánh mất một phần của agent. Vì vậy cách sạch nhất là coi compaction như một nhánh fork lossy theo kiểu best effort, một nhánh mà bạn có thể resume như một log mới.

7. Phản biện thứ hai: state nằm ngoài log

Phản biện thứ hai: còn những tool thay đổi state bên ngoài log thì sao? Điều đó đúng. Một agent có thể sửa một file, tạo một GitHub issue, gửi một email, nên rõ ràng có state nằm ngoài log. Nhưng điểm then chốt là log vốn không có nhiệm vụ chứa cả thế giới. Log chỉ là góc nhìn của agent về thế giới.

Slide The log isn't the whole world, it's the agent's view of it: cột World và cột Agent Log — "The log isn't the whole world, it's the agent's view of it": cột World gồm filesystem, GitHub, email, browser, APIs, database; cột Agent Log là event history, ghi lại agent đã làm gì, cái gì đã thay đổi, và những gì nó cần để đi tiếp.

Cũng giống như trong Skyrim: file save của Skyrim không chứa toàn bộ game engine hay mọi asset trên bản đồ. Nó chỉ chứa state riêng của người chơi, đủ để thả bạn trở lại thế giới đó. Log của agent cũng vậy. Log chỉ có thể resume hoặc lưu giữ một cách trung thực danh tính của agent và góc nhìn của nó về thế giới, nhưng nó không thể biến thế giới đó thành deterministic. Nếu agent đã gửi một email, fork ngược lại cũng không "huỷ gửi" được email đó. Nếu một file bị đổi ngầm bên dưới, agent sẽ không biết.

Nhưng việc của log là ghi lại agent đã làm gì, đã thấy gì, cái gì đã thay đổi, và nó cần gì để tiếp tục. Log lưu giữ danh tính đó, và đó là mục đích của nó. Cũng như file save của nhân vật Skyrim, log không có nhiệm vụ lưu cả thế giới, chỉ lưu góc nhìn của agent về thế giới.

8. Reliability: process chết, agent vẫn sống

Một khi bạn bắt đầu coi log là một primitive, hàng loạt thuộc tính của hệ thống sẽ tự rơi ra một cách tự nhiên.

Slide Once the log is the primitive, the properties fall out. — "Once the log is the primitive, the properties fall out": các thuộc tính phía sau không phải tính năng gắn thêm, mà là hệ quả của việc chọn log làm nền.

Thuộc tính đầu tiên là reliability. Hãy xem chuyện gì đang xảy ra hôm nay với Claude Code. Nếu bạn dùng Claude Code, agent của bạn dừng ở một permission prompt, rồi vì lý do nào đó process chết, và bạn resume lại, thì permission prompt sẽ biến mất và agent bị treo ở trạng thái tạm dừng. Trong production, điều đó không chấp nhận được. Permission prompt phải còn nguyên ở đó. Theo Ishaan, đây là dấu hiệu của một kiến trúc mà log không phải là agent.

Khi log là agent, executor được phép sai, được phép hỏng (fallible). Một worker mới sẽ nhận session, dựng lại state, và thấy permission prompt vẫn nằm đúng chỗ cũ. Nên dù process đã chết, agent không chết theo.

Slide Reliability: Worker dies, New worker reads log, Agent resumes — "Reliability": worker chết, một worker mới đọc log, agent tiếp tục. Không có bước nào cần process cũ còn sống.

9. Scalability: một process, hàng nghìn agent

Thuộc tính thứ hai là scalability. Phần lớn harness hiện nay chạy mỗi agent trong một process, nghĩa là agent bị trói vào cái máy đang chạy nó. Khi log là state, bạn lật ngược mô hình đó. Một process giờ có thể đẩy tiến hàng nghìn agent. Mỗi agent dựng lại state của mình từ log ở mỗi lượt (turn), và chúng không cần gắn với bất kỳ máy hay worker cụ thể nào.

Điều này làm failover trở nên tầm thường, và làm việc scale chỉ còn là chuyện thêm worker. Không có sticky session, không có migration state, không có chi phí phối hợp (coordination overhead).

Bên trái: mỗi agent sống trong một process trên một máy, máy chết thì agent mất, muốn scale phải giữ sticky session. Bên phải: worker không giữ state, mỗi lượt đọc log để dựng lại state rồi ghi nối kết quả, nên worker nào cũng tiếp nhận được session nào, failover và scale chỉ là thêm worker.

10. Forking: rẽ nhánh log sang nhiều model

Forking cũng trở nên tự nhiên hơn nhiều. Thay vì bị ép đi theo một con đường tuyến tính duy nhất, bạn có thể dễ dàng rẽ nhánh (branch) log. Một nhánh có thể chạy trên Claude, một nhánh khác chạy trên GPT, một nhánh nữa chạy trên open source model mà bạn thích. Mỗi nhánh giữ phần lịch sử cho tới điểm fork, rồi từ đó mỗi nhánh thử một chiến lược khác nhau.

Slide Forking: Session Log rẽ thành GPT Branch, Qwen Branch, Claude Branch — "Forking": một Session Log rẽ thành ba nhánh GPT, Qwen và Claude. Cả ba dùng chung lịch sử tới điểm rẽ nhánh, sau đó mỗi nhánh đi một hướng.

11. Multiplayer: chia sẻ agent là chia sẻ log

Multiplayer là một thuộc tính khác. Chia sẻ một agent với ai đó không nên có nghĩa là phải copy một đoạn hội thoại rồi dán vào Slack. Nếu log là agent, chia sẻ đơn giản là cấp quyền truy cập vào lịch sử đó, để người khác xem và chỉnh sửa được.

Một đồng đội có thể mở session, xem chuyện gì đã xảy ra. Một manager có thể quan sát mà không cần giành quyền điều khiển. Và thậm chí một agent khác cũng có thể dùng chính session đó làm context. Điều này thật sự quan trọng vì nó có nghĩa giá trị không chỉ nằm ở thứ agent làm ra, mà còn ở log, thứ cho thấy agent đã đi tới đó bằng cách nào.

Slide Multiplayer: một shared session log ở giữa, ba người Alex, Maya và Jordan nối vào — "Multiplayer": một Shared Session Log ở giữa, với ba người ở các vai trò khác nhau (engineer, product manager, designer) cùng nối vào. Ai được cấp quyền thì cùng xem và cùng làm trên một lịch sử.

12. Migration: đổi provider chỉ còn là bài toán adapter

Migration đi theo đúng pattern đó. Nếu danh tính của một agent bị nhốt trong những thread, memory, format và giả định runtime riêng của từng provider, việc chuyển provider sẽ rất đau đớn. Nhưng nếu log là agent, migration chỉ còn là một bài toán adapter.

Các model khác nhau có thể muốn những projection khác nhau của log, và các runtime khác nhau có thể cần những schema khác nhau, nhưng tất cả đều chỉ là bài toán kỹ thuật (engineering problem), không phải bài toán danh tính (identity problem). Khi đó agent có thể bắt đầu trên Claude, đi tiếp trên GPT, và hoàn thành trên Qwen mà không đánh mất chính mình. Log đóng vai trò nguồn của sự liên tục (source of continuity).

Slide Migration / Model Portability: Claude, GPT, Qwen nối vào cùng một dải log, chú thích Different models, same agent — "Migration / Model Portability": Claude, rồi GPT, rồi Qwen lần lượt chạy trên cùng một dải log liên tục. Chú thích dưới hình: "Different models, same agent".

13. Hôm nay, log thường chỉ là side effect

Và đây là vấn đề với khá nhiều hạ tầng agent hiện nay: phần lớn agent harness coi log là thứ tính sau (afterthought).

Claude Code và Codex ghi ra những file JSONL lộn xộn trên ổ đĩa local, và ngay cả ở chế độ Claude SDK, những lần ghi đó là fire and forget, nghĩa là nếu vì lý do nào đó lần ghi thất bại, data mất luôn. OpenCode là một ví dụ khác: họ lưu state trong một file SQLite, và có rất nhiều GitHub issue nói về state bị hỏng (corrupt) và mất data. Durable Objects thì thường kết thúc bằng việc mỗi object giữ một shard khác nhau, khiến việc dựng lại lịch sử trở nên khó, và truy vấn xuyên nhiều session cũng khó.

Slide Today, the log is often a side effect: Local JSONL, Local SQLite, Different shards — "Today, the log is often a side effect": 1. JSONL trên máy local (Claude Code và Codex), 2. SQLite trên máy local (OpenCode), 3. nhiều shard rời nhau (Durable Objects).

Trong tất cả các trường hợp đó, log chỉ là side effect, không phải là hệ thống. Và đó là vấn đề, vì khi bạn coi log là first-class citizen, tất cả các thuộc tính kể trên trở thành một phần của cấu trúc (structural). Bạn không phải gắn thêm (bolt on) chúng vào sau, mà theo Ishaan, đó là cảm giác về cách người ta đang làm hiện nay. Chúng đơn giản là tự rơi ra.

14. Ownership: lock-in sâu nhất là log lock-in

Ý tiếp theo, theo Ishaan, cực kỳ quan trọng, và nó dẫn tới chuyện ownership. Một khi đã chấp nhận rằng log là agent, thì dạng lock-in mạnh nhất không phải là model lock-in. Model có thể đổi được. Cũng không phải lock-in về API hay tool, vì những thứ đó có thể bọc lại (wrap) và chuyển đổi (adapt) được. Dạng lock-in sâu nhất thật ra là log lock-in. Nếu một provider sở hữu log của bạn, provider đó thực chất sở hữu agent của bạn.

Về lâu dài, log là phần có giá trị, vì model thay được, runtime thay được, máy thay được. Log là thứ tồn tại lâu dài.

Slide The deepest lock-in is log lock-in, hình một khối event bị nhốt trong lồng có khoá — "The deepest lock-in is log lock-in": 1. Model đổi được, 2. API và tool thay được, 3. Log bị khoá lại, sự liên tục bị mắc kẹt. Hình minh hoạ là một khối event nằm trong chiếc lồng có ổ khoá.

Anh làm thêm một slide riêng cho ý này vì cho rằng nó rất đáng được nhìn nhận nghiêm túc ngay lúc này. Anthropic có Claude Managed Agents. Google có Gemini Managed Agents. Mọi managed provider sẽ sở hữu ngày càng nhiều phần của stack. Họ sẽ muốn vậy. Họ sẽ muốn giữ hosted agent loop, managed memory, sandbox, compaction và background agent. Họ sẽ muốn sở hữu agent của bạn.

Và agent, có thể nói, là loại công nghệ riêng tư (intimate) nhất mà bạn từng chạy. Để một agent hữu ích, nó cần có data cá nhân của bạn, data của công ty bạn, workflow của bạn, các quyết định của bạn. Log là bản ghi của tất cả những thứ đó. Nếu log nằm trên hạ tầng của người khác, dưới chính sách của họ, và hệ thống của họ truy vấn được, thì họ không chỉ host agent của bạn, họ sở hữu nó.

Slide If the provider owns the log, they own the agent, hình một tháp dữ liệu phát sáng cạnh một tháp bị khoá màu đỏ — "If the provider owns the log, they own the agent": bên trái là một tháp log mở, phát sáng; bên phải là một tháp bị nhốt sau ổ khoá đỏ. Cùng một dữ liệu, khác nhau ở chỗ ai giữ chìa khoá.

15. Kiến trúc của Omnara: mọi thứ xoay quanh session log

Đây là kiến trúc mà Omnara đã và đang xây dựng hướng tới. Họ nghĩ về việc thực thi agent như một tập các thành phần được phối hợp xoay quanh log. Worker đẩy vòng loop tiến lên, nhưng worker không phải là agent, nó chỉ là executor. Worker gọi ra model provider, nhận kết quả, ghi kết quả trở lại log. Nếu model provider yêu cầu tool, worker sẽ dispatch các tool đó tới đúng môi trường thực thi để chạy xong ở một nơi khác. Tool chạy xong, kết quả được ghi nối trở lại log, rồi một worker, nhiều khả năng là một worker khác, sẽ dựng lại state và tiếp tục.

Sơ đồ kiến trúc Omnara: User or app, Omnara API, Durable Session Log, Worker, Model provider, Tools and approvals, Machine daemon — "What this looks like in practice - Omnara": User hoặc app gọi Omnara API, API ghi vào Durable Session Log. Worker đọc log, gọi Model provider và ghi kết quả về log; khi cần tool, việc đi qua Tools and approvals tới một Machine daemon, và kết quả của daemon cũng quay về log. Ba dòng tóm tắt: Worker đẩy vòng loop, Daemon khởi chạy task, Log vẫn là agent.

Điều này rất quan trọng vì đó là cách các hệ thống agent thật sẽ phải sống sót qua những lỗi của thế giới thật. Worker sẽ crash, máy sẽ khởi động lại, sandbox biến mất, tool call bị timeout, provider sập, user mất kết nối. Có quá nhiều thứ có thể hỏng, và nếu agent là một process đang chạy, điều đó cực kỳ đáng sợ. Nhưng nếu agent là log, tất cả những chuyện đó chỉ là chi tiết thực thi (execution detail).

Ishaan nói đây là cốt lõi của thứ Omnara đang xây: nền tảng managed agents open source mà họ sắp ra mắt. Mọi thứ sẽ được xây xoay quanh session log, và họ cam kết bạn hoàn toàn sở hữu được nó, kiểm tra (inspect) được toàn bộ, và nó hoàn toàn do bạn kiểm soát. Đó là điều họ tin tưởng mạnh mẽ. Ai quan tâm có thể xem tại omnara.com/managed; tới lúc video này lên sóng thì sản phẩm có thể đã phát hành, hoặc ở đó vẫn còn danh sách chờ (waitlist).

16. Kết: agent là data, log là agent

Để khép lại, điều chính Ishaan muốn người nghe mang về là: agent không chỉ là một lần gọi model. Nó không chỉ là một prompt, một vòng loop hay một sandbox. Nó không phải bất kỳ thứ nào trong số đó. Agent là lịch sử bền vững của công việc đang được làm, và lịch sử đó chính là log.

Một khi bạn bắt đầu nhìn theo cách này, rất nhiều thứ tự vào đúng chỗ: reliability, compaction, forking, migration, multiplayer, ownership, scalability, và còn nhiều nữa. Lý do là bạn sẽ thôi coi log như khí thải (exhaust) của hệ thống, và bắt đầu coi nó là chính hệ thống. Và điều đó cực kỳ quan trọng.

Slide kết Agents are data. The log is the agent. omnara.com/managed — Slide kết: "Agents are data. The log is the agent.", kèm địa chỉ omnara.com/managed.

Nếu talk này hữu ích, hãy theo dõi những gì Omnara đang xây. Như đã nói, họ đang chuẩn bị open source nền tảng managed agents của mình, và bạn có thể đăng ký tham gia ở địa chỉ trên. Log là agent chỉ là một trong vài mảnh ghép mà Omnara tin sẽ làm agent mạnh hơn rất nhiều trong tương lai. Ishaan cảm ơn mọi người đã theo dõi.