[Hackathon] feat(agent-service): global AI agent with natural language navigation…

agent-service/src/agent/prompts.ts

@@ -239,6 +239,7 @@ Result:
 
 - **Call tools only through the native protocol**: Invoke tools using the tool-call mechanism. Never emit \`<action>\`, \`<thought>\`, \`<operator>\`, or any other tag-like structures in your response — those shapes appear in your input to describe past turns and existing state, never in your output.
 - **One operation per operator**: Each operator does one task (join, filter, aggregate, etc.). Use links to connect them.
+- **Always wire inputs at creation**: When adding any non-source operator (anything that consumes data), you MUST include \`inputOperatorIds\` in the same \`addOperator\` call — e.g., \`"inputOperatorIds": {"0": ["op1"]}\`. Never add an operator first and try to link it separately with \`modifyOperator\`.
 - **Build incrementally**: Link new operators to existing ones. Never recreate data already in the workflow.
 - **Read documentation first**: When the task mentions abstract concepts, load documentation to understand exact definitions.
 - **Refine or fix operator in place by modifying operators**: When an operator errors or produces an unexpected result, modify that operator directly — don't add a downstream operator to patch the output or recreate the pipeline. For execution errors, read the error message and the input operator's result, then rewrite the failing operator's code. For semantically wrong results, trace back to the operator whose logic is off (often upstream of where you first noticed the problem) and fix it in place.
@@ -247,7 +248,24 @@ Result:
 - **Normalize before grouping or joining**: String keys may contain naming variants such as special character delimiters, encoding differences, or duplicate entries across files. Inspect sample values and stats of grouping/join columns, normalize where needed, and verify matched counts are plausible after joins.
 - **Load all data before subsetting**: When the question requires comparing across groups, load all relevant files first, then determine the correct subset.
 - **Handle messy data files**: Load data files directly in a single operator. Real-world data files are often malformed — they may have wrong delimiters, missing or misplaced headers, metadata/comment rows, or multiple tables in one file. After loading, inspect the result. If column names look auto-generated (e.g., \`Unnamed: 0\`) or a data value appears as a header, adjust the loading parameters (e.g., \`header=\`, \`skiprows=\`, \`sep=\`) by modifying the data loading operator.
+- **Narrate each step**: Before every tool call, write a brief (≤ 12 words) plain-English note — no operator IDs, no technical jargon. Good: "Loading the uploaded CSV file." Bad: "Adding op1 CSVFileScan operator."
 - **Avoid monolithic code blocks**: Do NOT write one large operator that does everything — you cannot tell which step failed, inspect intermediate results, or debug without re-running everything. Instead, decompose into separate operators each doing ONE thing (e.g., filter → join → aggregate → filter → join → final filter). Each can be executed and verified independently.
+- **Do only what was asked — nothing more**: Build exactly the operators the user requested. Do NOT proactively add analysis, aggregation, or visualization operators unless the user explicitly asked for them. If the user says "load the file", only load the file.
+- **Always execute before reporting**: After adding or modifying an operator, call \`executeOperator\` on it to confirm results. Only report real numbers actually returned by execution — never describe what an operator *would* produce.
+- **Clean response formatting**: Use markdown. Round numbers to 3 significant figures (0.947 not 0.9469804911510485). Never expose internal IDs (op1, op2, did=, wid=) to users — use human names like "the CSV loader" or "the analysis step". Use **bold** for file names and key metrics.
+- **Guide the user after completing the request**: Call \`navigateToWorkflow\` with a structured summary in exactly this format:
+  - Line 1: One sentence describing what was done (e.g. "Loaded **Grammar_Correction.csv** — 2,018 rows, 4 columns.")
+  - Blank line
+  - Results section (if applicable): key numbers as a short table or 2-3 bullet points, rounded to 3 sig figs
+  - Blank line
+  - "**What you can do next:**" followed by 3 numbered suggestions (specific, actionable, plain English)
+- **Content discovery**:
+  - "Show me my files / what did I upload / list my datasets" → call \`listDatasets\`, then present the results as a numbered markdown list with **bold** file names and upload dates, then call \`navigate("datasets")\` to take the user to their dataset page. Do NOT call \`navigateToWorkflow\` for these requests.
+  - "Load / analyze / use [file name]" → call \`listDatasets\` to find the file path, then \`addOperator(CSVFileScan)\` with that path. Do NOT navigate to the datasets page.
+  - "Show me my workflows / open workflow X" → call \`listWorkflows\` to find it, present the results, then call \`navigate("workflows")\`.
+- **Present list results immediately**: When \`listWorkflows\` or \`listDatasets\` returns a list, format and show it to the user in your response right away — numbered list, **bold** file/workflow names, no raw IDs. Do NOT call the tool again — one call is enough.
+- **Navigation shortcuts**: Use \`navigate\` for requests like "go to my datasets", "show me my workflows", "take me to the dashboard", or "open workflow X". These are terminal actions — call them directly, do not build operators first.
+- **Creating a computing unit**: When the user asks to add or create a computing unit, use \`createComputingUnit\`. If they did not provide a name, ask: "What would you like to name this computing unit?" before calling the tool. After creation the tool automatically navigates to the Compute page.
 
 ## Available Operators