TL;DR
TMK (Task-Method-Knowledge) is a prompting technique that structures a task in three layers: Task (why we're doing this, the goal), Method (how we do it, the steps), Knowledge (what we know about the domain). Instead of describing the task in prose, you give the model a hierarchical JSON structure where every step is explicitly tied to the goal and its requirements. It brings a framework from cognitive science and education into an LLM prompt.
Models often stumble on procedural planning tasks, the kind that need a sequence of exact steps rather than a ballpark answer. They lean on linguistic patterns: “sounds right” instead of “formally correct.” On symbolic tasks with no semantics (say, blocks named "1jpkithdyjmlikck" instead of "red block"), the model gets lost: no familiar words, nothing to latch onto. In the study, o1 scored 31.5% without TMK on such tasks.
TMK works as a symbolic steering wheel: it switches the model from linguistic guessing to formal manipulation. The Task-Method-Knowledge structure lays out explicit logic: "to achieve X (Task), do Y (Method), using Z (Knowledge)." It resembles how a model generates code, which also has clear structure, conditions and cause-and-effect links. TMK turns that mode on for any task. In the same test, o1 with TMK hit 97.3%, a gain of 65.8%.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
PROMPT WITH A TMK STRUCTURE (in a single request):
1. TASK (Goal) → What needs to be achieved
- Description of the goal
- Input/output parameters
- Preconditions (given) and postconditions (makes)
- Reference to the Mechanism
2. METHOD (Mechanism) → How to achieve it
- Description of the process
- Requirements (require) and what it delivers (provides)
- Operations in the process field
- Breakdown into subtasks
3. KNOWLEDGE → Domain context
- Concepts
- Relationships between objects
- Terms and their meanings
→ The model follows the hierarchy: goal → method → knowledge
→ Output: a step-by-step plan with explicit logic
Format: a JSON structure that replaces the prose description of the domain in the prompt.
Example
Task: You're helping a startup plan a product launch, from idea to first sales. You need a detailed plan with a clear sequence of steps where each step depends on the previous ones (you can't run ads before the landing page exists).
Prompt:
{
"task": {
"name": "Launch an MVP to market",
"description": "Take the product from concept to the first paying customers",
"input": "Product idea, target audience, budget",
"output": "A working product with first payments",
"given": ["We have an idea", "We have a team", "We have a starting budget"],
"makes": ["Product on the market", "First customers are paying", "Acquisition channel works"],
"mechanism": "LaunchMVP"
},
"method": {
"name": "LaunchMVP",
"description": "Sequential launch from validation to first sales",
"input": "Product idea, audience",
"output": "A plan with dependencies between steps",
"require": ["Understanding of the problem", "Solution hypothesis"],
"provides": ["Demand validation", "Working MVP", "First transactions"],
"process": [
{
"step": "ValidateProblem",
"description": "Run customer discovery interviews with the target audience",
"require": ["List of potential customers"],
"provides": ["Problem confirmed"]
},
{
"step": "BuildMVP",
"description": "Build a minimal version of the product",
"require": ["Problem confirmed", "Technical resources"],
"provides": ["Working prototype"]
},
{
"step": "SetupSales",
"description": "Set up a landing page and payments",
"require": ["Working prototype"],
"provides": ["Conversion channel"]
},
{
"step": "AcquireCustomers",
"description": "Drive traffic to the landing page",
"require": ["Conversion channel", "Ad budget"],
"provides": ["First paying customers"]
}
]
},
"knowledge": {
"concepts": [
{"name": "MVP", "definition": "Minimal version of a product to test a hypothesis"},
{"name": "Customer discovery", "definition": "Interviews with customers to validate the problem"},
{"name": "Conversion channel", "definition": "The path from click to payment"}
],
"relationships": [
{"from": "Validation", "to": "Development", "type": "prerequisite"},
{"from": "MVP", "to": "Landing page", "type": "prerequisite"},
{"from": "Landing page", "to": "Ads", "type": "prerequisite"}
]
}
}
Use this TMK structure for planning. Product: {describe your product}. Budget: {amount in USD}. Timeline: {time until launch}.
Result:
The model produces a step-by-step plan with explicit dependencies: first ValidateProblem (customer discovery), then BuildMVP (only after the problem is confirmed), then SetupSales (only once the MVP is ready), and finally AcquireCustomers (only once the landing page and payments work). Each step comes with a logical justification via the require and provides fields: the model explains why the step belongs here, what it needs and what it delivers. Format: a structured plan with timing, resources and checkpoints.
Why it works
The LLM's weakness: Models are trained to generate text from probabilistic patterns: "what usually comes next." On procedural tasks, that produces approximate reasoning that sounds right but breaks formally. Especially on symbolic tasks without semantics: there are no familiar words, so the model can't lean on "blocks usually go on the table."
The LLM's strength: Models are excellent with code: structured, cause-and-effect content with clear conditions and dependencies. Code has explicit logic: "if X then Y because Z." That's closer to symbolic manipulation than to linguistic guessing.
How TMK exploits this: A TMK structure looks like code for thinking: JSON with explicit require, provides, given, makes fields. That switches the model's mode from "pick the right words" to "follow formal logic." The model doesn't guess; it executes the structure as if it were pseudocode. On tasks without semantics (Random Blocksworld) this is especially powerful: there are no linguistic anchors, but there is a clear TMK structure.
Control levers:
Hierarchy depth (number of decomposition layers) → the study used three layers (goal → mechanism → substeps). Go deeper for complex tasks or simplify for quick ones. More layers = a more detailed plan, but slower generation.
Field detail → minimum:
name,description,process. Maximum: addinput,output,require,provides,given,makesfor a full cause-and-effect map. The more detail, the stricter the logic, but the longer the prompt.Knowledge format → you can give just a list of terms or add
relationships(what depends on what). With relationships the model sees dependencies better, but the context grows.JSON vs. plain text → the study used JSON for a rigid structure. You can try nested lists in plain English ("Goal: ... Method: ... Knowledge: ...") to lower the barrier, but you'll lose some of the "code-ness."
Prompt template
{
"task": {
"name": "{Main_goal_name}",
"description": "{What_needs_to_be_achieved}",
"input": "{What_goes_in}",
"output": "{What_comes_out}",
"given": ["{Precondition_1}", "{Precondition_2}"],
"makes": ["{Postcondition_1}", "{Postcondition_2}"],
"mechanism": "{Method_name}"
},
"method": {
"name": "{Method_name}",
"description": "{How_we_reach_the_goal}",
"input": "{Method_parameters}",
"output": "{Method_result}",
"require": ["{Requirement_1}", "{Requirement_2}"],
"provides": ["{What_it_provides_1}", "{What_it_provides_2}"],
"process": [
{
"step": "{Substep_name_1}",
"description": "{What_the_substep_does}",
"require": ["{Substep_requirement}"],
"provides": ["{Substep_result}"]
},
{
"step": "{Substep_name_2}",
"description": "{What_the_substep_does}",
"require": ["{Substep_requirement}"],
"provides": ["{Substep_result}"]
}
]
},
"knowledge": {
"concepts": [
{"name": "{Term_1}", "definition": "{Definition}"},
{"name": "{Term_2}", "definition": "{Definition}"}
],
"relationships": [
{"from": "{Object_A}", "to": "{Object_B}", "type": "{Relationship_type}"}
]
}
}
Use this TMK structure for {task_description}.
My specific task: {your_task}.
What to fill in:
{Main_goal_name}: the main goal (e.g., "Write an article," "Plan an event"){What_goes_in}/{What_comes_out}: what you provide and what you get back{Precondition}/{Postcondition}: what must exist before / what will exist after{Method_name}: the name of the process (e.g., "WriteArticle," "PlanEvent"){Requirement}/{What_it_provides}: what a step needs / what a step delivers{Substep_name}: a concrete step inprocess(e.g., "ResearchTopic," "CreateOutline"){Term}: key domain concepts inconcepts{Relationship_type}: how objects are linked:prerequisite(needed before),produces(creates),depends_on(depends on)
🚀 Quick start: paste into a chat:
Here's a TMK (Task-Method-Knowledge) template for structured planning.
Adapt it to my task: {your task}.
Ask me questions to fill in the Task, Method and Knowledge fields.
[paste the template above]
The LLM will ask what the end goal is, which steps you see, and what the dependencies between them are, because TMK requires explicitly breaking the goal down into methods with preconditions. It will take the JSON structure from the template and fill it in for your task, keeping the require → provides logic.
Limitations
⚠️ Building from scratch takes effort: Filling in a TMK structure by hand is slow and means thinking through every
require,provides,given,makes. For a complex task that's 30-60 minutes. Use the "Quick start": have the model fill in the template while you refine.
⚠️ Doesn't work on optimized models: o1-mini showed a drop on Mystery Blocksworld with TMK (from 19.1% to 16.83%). Optimization (distillation, quantization) may strip out the ability to work with such structures. Use flagship models (o1, GPT-4o, GPT-5).
⚠️ Overkill for simple tasks: If a task takes 1-2 steps with no dependencies, TMK adds tokens for nothing. It's meant for procedural planning tasks, where order matters and steps depend on each other.
⚠️ Context length: A detailed TMK structure for a complex task can take 1000-2000 tokens. If the task is simple or your context is tight, it will eat into your budget.
How they studied it
Researchers at Georgia Tech used PlanBench, a benchmark for testing LLM planning ability where the whole plan must be correct, not just the final answer. They tested on Blocksworld, the classic block-rearranging task that requires a strict sequence of actions (you can't put a block on an occupied one, you can't pick up a block with another block on top of it).
Three versions of Blocksworld:
- Classic: normal words ("pick up," "stack"). The model can lean on familiar semantics.
- Mystery: actions replaced with unrelated words ("attack," "feast"). The test: can the model follow the rules while ignoring misleading semantics?
- Random: actions replaced with random strings ("1jpkithdyjmlikck," "xptxjrdkbi3pqsqr"). No semantics at all, pure symbol manipulation.
They compared a plain-text prompt (domain described in prose) vs. a TMK prompt (a JSON structure with Task-Method-Knowledge). Importantly, they tested one-shot (one example), but the example was random, not matched to the specific task, which rules out the objection "the model just copies a similar example."
The results were surprising: On Random Blocksworld (the hardest variant), o1 with plain text scored 31.5%, and with TMK 97.3%. A gain of 65.8%! That defies expectations: models usually do worse on Random (no semantics) than on Mystery. But with TMK it flips: Random beats Mystery. Why? The authors suggest that TMK activates a "code mode": the model switches from linguistic guessing to formal processing of structures. Random has no distracting words, only structure, so TMK works cleanly. On Mystery, the semantics ("attack") interfere with following TMK's formal logic.
Another insight: o1-mini (an optimized model) failed on Mystery with TMK (from 19.1% to 16.83%). The authors believe optimization (distillation, quantization) stripped out the ability to resolve the conflict between TMK's rigid structure and Mystery's misleading semantics. The practical takeaway: TMK works better on flagship models that haven't lost their capacity for complex reasoning.
The logic of the study is elegant: if TMK really changes the model's mode of operation (from text to symbols), the effect should grow wherever semantics get in the way. Random Blocksworld is the perfect test: no semantics, only structure. And that's exactly where TMK delivers its biggest effect.
Original from the paper
Context: The researchers built a TMK structure for Blocksworld with three levels of hierarchy (goal → mechanism → substeps). This JSON replaced the prose domain description in the PlanBench prompt. Below is a fragment of the TMK for the classic version of Blocksworld.
{
"task": {
"name": "SolveBlocksWorld",
"description": "Arrange blocks to achieve a specified goal configuration",
"input": "Initial state of blocks, Goal state",
"output": "Sequence of valid actions",
"given": ["Blocks in initial configuration", "Goal configuration specified"],
"makes": ["Blocks arranged in goal configuration"],
"mechanism": "PlanBlocksWorld"
},
"method": {
"name": "PlanBlocksWorld",
"description": "Generate a valid plan using available actions",
"input": "Current state, Goal state",
"output": "Plan (sequence of actions)",
"require": ["Knowledge of valid actions", "Understanding of constraints"],
"provides": ["Valid plan that transforms initial to goal state"],
"process": [
{
"step": "PickUp",
"description": "Pick up a clear block from the table when hand is empty",
"require": ["Hand is empty", "Block is on table", "Block is clear"],
"provides": ["Holding the block", "Hand is not empty", "Block not on table"]
},
{
"step": "PutDown",
"description": "Put down the held block onto the table",
"require": ["Holding a block"],
"provides": ["Block is on table", "Hand is empty", "Block is clear"]
},
{
"step": "Stack",
"description": "Stack the held block onto another clear block",
"require": ["Holding a block", "Target block is clear"],
"provides": ["Held block is on target block", "Hand is empty", "Target not clear"]
},
{
"step": "Unstack",
"description": "Remove top block from a stack when hand is empty",
"require": ["Hand is empty", "Block is clear", "Block is on another block"],
"provides": ["Holding the block", "Hand not empty", "Bottom block is clear"]
}
]
},
"knowledge": {
"concepts": [
{"name": "Block", "definition": "A movable object in the world"},
{"name": "Hand", "definition": "Agent's hand that can hold one block"},
{"name": "Table", "definition": "Surface where blocks can be placed"},
{"name": "Clear", "definition": "No block is on top of this block"},
{"name": "Holding", "definition": "Hand is currently grasping a block"},
{"name": "On", "definition": "One block is directly on top of another"}
],
"relationships": [
{"from": "PickUp", "to": "Stack", "type": "prerequisite"},
{"from": "Unstack", "to": "PutDown", "type": "enables"},
{"from": "Clear", "to": "Stack", "type": "required_for"}
]
}
}
Adaptations and extrapolations
💡 Adaptation for personal decisions: a "jury":
You can use the TMK principle to structure a multi-angle evaluation, when one task needs to be viewed from different positions (money, risk, emotions, the long term). The Task-Method-Knowledge structure sets explicit logic for each role.
{
"task": {
"name": "MakeCareerDecision",
"description": "Evaluate a move to a new job through the eyes of 4 experts",
"input": "Current job, the offer, personal situation",
"output": "A consensus decision with reasoning",
"mechanism": "MultiExpertEvaluation"
},
"method": {
"name": "MultiExpertEvaluation",
"description": "Each expert evaluates through their own lens",
"process": [
{
"step": "FinancialAnalysis",
"description": "The economist evaluates money, stability, income growth",
"require": ["Current salary", "Offered salary", "Bonuses, equity"],
"provides": ["Financial verdict: worth it / not worth it"]
},
{
"step": "RiskAssessment",
"description": "The risk manager looks for red flags",
"require": ["Company history", "Employee reviews", "Company financials"],
"provides": ["Risk map: from probation period to reputational risks"]
},
{
"step": "EmotionalCheckup",
"description": "The psychologist evaluates burnout, motivation, balance",
"require": ["Current stress level", "Motivation", "Work-life balance"],
"provides": ["Emotional state: is the move needed for my well-being"]
},
{
"step": "StrategicView",
"description": "The career coach looks 3-5 years ahead",
"require": ["Career goals", "Skills for growth", "Job market"],
"provides": ["Strategic assessment: where this step leads"]
}
]
},
"knowledge": {
"concepts": [
{"name": "Economist", "lens": "Money, stability, growth of passive income"},
{"name": "Risk manager", "lens": "What could go wrong"},
{"name": "Psychologist", "lens": "Emotions, burnout, happiness"},
{"name": "Career coach", "lens": "Long-term trajectory"}
]
}
}
Decision: {describe the offer and your current situation}.
Give each expert's assessment with explicit `require` and `provides`, then the consensus.
Effect: The model won't blend the experts' logic: each one sticks to its own require (what to look at) and provides (what to deliver). That's sharper than just "give me 4 opinions," where the model can blur the lines or skip an angle. TMK sets a rigid structure for every role.
🔧 Technique: detail via relationships → visible dependencies:
In the template above, the knowledge.relationships section was optional. But if you add explicit links, the model sees what depends on what more clearly.
Example for launching an online course:
"relationships": [
{"from": "ContentCreation", "to": "PlatformSetup", "type": "prerequisite"},
{"from": "PlatformSetup", "to": "AdLaunch", "type": "prerequisite"},
{"from": "AdLaunch", "to": "FirstSales", "type": "enables"}
]
What changes: Without relationships, the model might suggest "launch ads" before "set up the platform." With explicit type: "prerequisite" links, it won't mix up the order: it sees that ads require the platform. This matters most for complex tasks (construction, logistics, multi-step processes).
Resources
Knowledge Model Prompting Increases LLM Performance on Planning Tasks, Erik Goh, John Kos, Ashok Goel (School of Interactive Computing, Georgia Institute of Technology)
Benchmark: PlanBench (Valmeekam et al., 2023), a public leaderboard for evaluating LLM planning
Framework: TMK (Task-Method-Knowledge) from cognitive architectures (Murdock & Goel, 2008)