Agents

Agents는 LLM이 답변만 생성하는 것이 아니라, context를 모으고, tool을 쓰고, state를 추적하고, 결과를 검증해서 작업을 끝내는 방식입니다.

이 섹션은 제품 기능 목록보다 오래 남는 agent의 원리를 먼저 봅니다. 핵심은 model, context, tools, state, verification이 어떻게 묶여 하나의 작업 흐름을 만드는지입니다.

Agent Contract

Agent 글은 “LLM이 똑똑하다”가 아니라, 어떤 관찰을 보고 어떤 행동을 하며 어떤 증거로 완료를 판단하는지를 설명해야 합니다.

PartMeaningNote location
model policy or reasoning surface[[agents/models/index
observations and context[[agents/core/context-engineering
allowed actions[[agents/core/action-space
current task state[[agents/core/agent-state
reusable memory or knowledge[[agents/core/agent-memory
tool interface[[agents/tools/tool-contract
verifier or completion rule[[agents/verification/index

The practical question is:

먼저 볼 지도

질문볼 곳
agent가 내부적으로 어떻게 움직이는가?Core
사용자가 실제로 누르는 기능은 무엇인가?Features
tool call, connector, side effect는 어떻게 다루는가?Tools
coding, paper brief, LLM Wiki 같은 반복 작업은 어떻게 묶는가?Workflows
ChatGPT, Claude, Gemini, Copilot은 어떤 agent surface를 갖는가?Models
agent 결과를 어떻게 검증하고 완료 판단하는가?Verification

섹션

섹션담는 것대표 노트
Corearchitecture, loop, state, memory, planningAgent loop, Context engineering
Featureschat, files, research, coding, memory, canvas, connectorsFiles and knowledge, Coding workspace
Toolstool contract, permission, result handlingTool use, Tool contract
Workflows반복 가능한 작업 절차Coding agents, LLM Wiki
Models공개 제품군의 agent interfaceChatGPT, Claude
Verificationacceptance criteria, evidence, audit, safetyVerification loop, Completion audit

분류 기준

내용둘 곳
prompt, context, memory, planning처럼 agent를 이루는 부품Core
사용자가 보는 기능 이름과 사용 패턴Features
외부 상태를 읽거나 바꾸는 인터페이스Tools
여러 단계로 반복되는 작업 방식Workflows
제품별 차이와 interface 비교Models
결과가 맞는지 확인하는 기준과 절차Verification
model architecture, loss, training method 자체AI, Architectures, Learning methods
서버, repo, browser, job 같은 실행 환경Infra, AI Systems

Workflow View

Agent workflow는 다음 항목을 분리해서 써야 비교가 됩니다.

FieldWrite
Taskcoding, paper curation, wiki maintenance, review, browsing, deployment
Inputsuser request, files, paper metadata, repo state, browser state, prior notes
Toolsread-only tools, write tools, browser, shell, GitHub, search, local agents
Statetodo list, current branch, open runs, unresolved decisions
Side effectsfile edit, commit, push, PR, issue, message, public page update
Verificationtests, build, rendered page, source citation, human review, completion audit
Public boundarysecrets, private paths, account names, unpublished work, collaborator details

This keeps product usage notes from turning into vague impressions. A workflow note should say what changed, what evidence was checked, and what remains uncertain.

Agent vs Automation vs Workflow

TermMeaningExample note
Agent coregeneric mechanism of context, state, tools, and verification[[agents/core/agent-loop
Product featureuser-facing capability exposed by a product[[agents/features/files-and-knowledge
Tooltyped interface that reads or mutates external state[[agents/tools/tool-use
Workflowrepeatable procedure that uses an agent to finish a task[[agents/workflows/coding-agents
Automationscheduled or event-driven workflow with less human prompting[[agents/workflows/agent-runbook
Evaluationevidence that an agent behavior meets a claim[[agents/verification/agent-evaluation

Good Agent Notes

Weak noteBetter note
“This agent is good at coding.”Define the coding task, allowed edits, tests, and review evidence.
“Tool use makes it powerful.”State the tool contract, side effects, retry behavior, and verifier.
“It remembered context.”Separate current context, durable memory, retrieved knowledge, and user-provided state.
“It finished the task.”Link completion to acceptance criteria and evidence.
“Multi-agent review helped.”Say what independent evidence or failure mode each reviewer checked.

작성 규칙

  • 개인 자동화보다 공개 제품에서 공통으로 보이는 pattern을 우선합니다.
  • 세부 개념은 Core, Tools, Workflows, Verification 같은 안정적인 묶음 안에서 연결합니다.
  • vendor-specific claim은 변동 가능성이 크므로 날짜, 범위, 공식 문서 확인 필요성을 남깁니다.
  • private prompt, private repo detail, credential, internal task name, unpublished work는 공개하지 않습니다.
  • “agent가 잘했다”보다 어떤 evidence로 확인했는지를 남깁니다.
  • 제품 이름은 바뀔 수 있으므로 durable concept와 product surface를 분리합니다.
  • side effect가 있는 workflow는 항상 verification과 rollback 또는 handoff 기준을 함께 씁니다.