Your First Hour with an AI Terminal

First: what is a terminal anyway?

Don't be intimidated. A terminal is just a text box with superpowers. If you can type a sentence, you can use one.

Why put AI in a terminal at all?

Speed. No tabs, no loading, no copy-paste. Ask and get an answer in place.
Context. The AI can read your project, files, and notes directly. It isn't guessing from a chat box.
Automation. The AI can actually run commands and edit files, not just talk about them.
Focus. A clean text interface, no banners or popups, ideal for long sessions.

AI fundamentals, better prompting, grounded research, agentic workflows, and your first serious project—explained without assuming technical experience.

A terminal can look hostile the first time you open one.

There is no welcoming dashboard. No row of colorful buttons. No obvious place to begin. Just a cursor blinking inside a mostly empty window, waiting for you to type something precise.

That emptiness is the point.

A terminal is one of the most direct ways to communicate with a computer. When artificial intelligence moves into that environment, it becomes more than another chatbot. It can work with files, inspect projects, search a knowledge base, run tools, preserve research, and help turn an idea into an actual artifact.

The important shift is not from “website” to “terminal.” It is from an AI that only talks about work to an AI that can participate in the work.

This guide will take you from zero to a useful mental model of modern AI. You will learn:

What a terminal actually is
What language models do—and what they do not do
How tokens, context windows, retrieval, tools, and agents fit together
How to write prompts that produce dependable results
How to use Expert AI for research, coding, documents, and knowledge work
How to tell grounded evidence from confident invention
How to complete a meaningful first-hour project
How to decide when AI should act, when it should ask, and when you should verify

You do not need to be a programmer. You do need curiosity, a willingness to experiment, and enough skepticism to inspect important results.

That combination—curiosity plus verification—is the beginning of AI literacy.

Install & start the Expert AI terminal

Download the installer for your system — Windows, macOS (Apple Silicon or Intel), or Linux. It is only about 3 MB, with zero dependencies.
Run it. The installer sets up its own private runtime, there is no Node or npm required.
Sign in. On first run, it asks for your email and opens ssv.asia in your browser. Confirm there, and you are activated.
Start. Type your first prompt. Free tokens are ready immediately.

$ expert-ai Sign in with your email: you@example.com ↳ Opening ssv.asia… ✓ Confirmed. $ Ask "explain this codebase to a beginner" →

Total time: under 60 seconds. That is deliberate. Onboarding should never be a project.

Is it free to start?

Separate product: Expert AI Terminal Pro — the $195 desktop/USB terminal — is not the x CLI this guide is about. If you type x, you are on Expert AI, free to start.

First: what is a terminal?

A terminal is a text interface for controlling a computer.

On Windows, you may know it as PowerShell, Windows Terminal, or Command Prompt. On macOS and Linux, the default application is usually called Terminal. Developers sometimes call the environment a shell or command-line interface, often shortened to CLI.

These terms describe slightly different layers, but a beginner can use this practical definition:

A terminal is a text window where you type an instruction, press Enter, and receive a result.

Before graphical interfaces became common, terminals were the normal way to use computers. Today they remain important because text commands are fast, repeatable, automatable, and easy to combine.

In a graphical file manager, you might:

Open a folder.
Find a file.
Right-click it.
Select an action.
Confirm the action.

In a terminal, the same operation may be expressed in one line.

That does not automatically make the terminal better. A graphical interface is often easier for visual browsing, direct manipulation, and casual use. The terminal becomes powerful when the task is repetitive, precise, connected to other tools, or spread across many files.

Traditional terminals require you to remember commands. An AI terminal changes the relationship. Instead of knowing the exact command in advance, you can describe the desired outcome:

Find every Markdown document in this project that mentions “embodied carbon,” group the results by folder, and summarize the strongest themes.

The AI can translate that intention into searches, file reads, and a structured response.

The terminal remains the work surface. AI becomes the interpreter between human intention and computational action.

A text box with superpowers

If you can type a sentence, you can begin using an AI terminal.

That does not mean every sentence will produce a good result. It means the barrier to entry is no longer memorizing a command manual. You can start in ordinary language and gradually learn how to express tasks with more structure.

The cursor is not testing whether you belong there. It is waiting for a useful instruction.

Why put AI in a terminal at all?

A web chatbot is excellent for conversation. It is accessible, familiar, and deliberately separated from most of your computer. That separation can also be its limitation.

Imagine asking an ordinary chatbot:

Review my project and tell me which documents contradict one another.

Unless you upload the documents, the chatbot cannot see them. If the project changes, you must upload them again. If its answer identifies ten edits, you still have to perform those edits yourself.

An AI terminal can work inside the project itself. Depending on the permissions and tools you provide, it can inspect the directory, search documents, compare versions, run scripts, create a report, and apply approved edits.

Four differences matter.

1. Context

A chat box knows what you paste into it. A terminal agent can be given access to the files and directories relevant to the task.

That changes the quality of the conversation.

“Improve this document” is vague when the AI has only one pasted paragraph. The same instruction becomes more meaningful when the AI can inspect the document, its references, neighboring notes, project conventions, and previous drafts.

Context is not unlimited awareness. The AI does not automatically understand your entire machine. It knows what its tools can access and what it actually chooses or is instructed to inspect.

A responsible agent should distinguish between:

Files it read
Files it merely discovered
Claims it verified
Claims it inferred
Information it could not access

That distinction is fundamental to trustworthy work.

2. Action

A chatbot usually recommends actions. An agent can perform actions.

It may:

Create and edit files
Search folders
Run tests
Parse documents
Generate charts
Inspect a codebase
Compare sources
Organize research notes
Prepare a publishable draft
Monitor a process
Build a repeatable workflow

Action introduces both usefulness and risk. An agent that can edit a file can also edit the wrong file. An agent that can run a command can run an inappropriate one.

The goal is not maximum autonomy at all times. The goal is appropriate autonomy.

A low-risk task such as reading a folder can usually proceed directly. A destructive or consequential task—deleting records, publishing content, changing production infrastructure, sending messages—deserves tighter confirmation and verification.

3. Repeatability

A terminal command can be repeated. A workflow can be saved. A research process can leave an audit trail.

This is a major difference between casually receiving an answer and constructing a dependable system.

Suppose you need a weekly competitor brief. You could manually ask the same questions every Friday, search the same websites, and format the same report. Or you could define a workflow that searches approved sources, records dates, compares changes, and produces the report in the same structure each week.

Repeatability transforms AI from an occasional helper into infrastructure.

4. Focus

A terminal is quiet.

It does not need a feed, a carousel, or a collection of engagement mechanisms. The interface can remain almost empty while the work behind it becomes sophisticated.

That austerity is useful for long sessions. You see the instruction, the response, and the artifacts being created. The conversation remains attached to the work.

The five-layer model of practical AI

People often use “AI” to describe an entire stack of different technologies. That makes discussions confusing.

A language model, a chatbot, an agent, a search system, and an AI product are not the same thing.

A useful mental model has five layers:

The model
The context
Retrieval
Tools
The agent or harness

Understanding these layers will make you a better user immediately.

Layer one: the model

A large language model, or LLM, is a system trained to predict sequences of tokens.

That description sounds underwhelming because the resulting behavior can be remarkably sophisticated. By learning statistical relationships across enormous quantities of text and code, a model becomes able to draft, classify, translate, summarize, explain, plan, and reason through many problems.

But it is still important to remember what the model is doing.

It is generating a plausible continuation based on:

Patterns learned during training
The instructions it has received
The conversation and documents in its current context
Results returned by any tools it can use

A model is not a database that retrieves a perfectly stored answer. It reconstructs an answer token by token.

This explains both its flexibility and its failures.

A database is rigid but dependable within its schema. A language model is flexible but probabilistic. It can connect ideas expressed in different words, yet it can also produce a confident statement that is unsupported or false.

The correct response is not to distrust every output. It is to match verification to consequence.

Brainstorming ten names for a private folder requires little verification. Quoting a fire-safety requirement for a building submission requires direct inspection of the authoritative source.

Layer two: context

The context is the information available to the model during a particular request.

It may include:

Your current prompt
Earlier messages
System instructions
Selected files
Retrieved passages
Tool results
Stored project notes
A summary of previous work

Models have context limits. They cannot consider an infinite amount of material at once. Even when a system advertises a large context window, filling that window indiscriminately is rarely the best strategy.

More context is not always better context.

If you place forty unrelated documents into a request, the model must decide which details matter. Relevant evidence may be diluted by noise. A better system retrieves the smallest set of passages likely to answer the question and tells the model where they came from.

Think of context as a working desk. A larger desk can hold more material, but dumping an entire archive onto it does not improve concentration.

Layer three: retrieval

Retrieval finds relevant information before the model answers.

This is often called retrieval-augmented generation, or RAG. The basic pattern is straightforward:

You ask a question.
The system searches a document collection.
It selects relevant passages.
Those passages enter the model’s context.
The model answers using the retrieved evidence.

Retrieval helps solve two problems.

First, a model’s training data may not contain your private or specialized information. It cannot know the contents of your Obsidian vault, company handbook, project specification, or licensed building-code collection unless that material is made available.

Second, even when a model has encountered a fact during training, it may not reproduce it reliably or identify its source. Retrieval gives it evidence to work from.

Retrieval does not guarantee truth. The search may find the wrong passage. The corpus may contain obsolete material. The model may misread the evidence.

A strong retrieval system therefore preserves provenance:

Which document was searched?
Which passage was retrieved?
Was the passage quoted accurately?
Is the document authoritative?
Is it current?
Does the final claim actually follow from it?

A citation is not decoration. It is a route back to the evidence.

Layer four: tools

Tools let the model interact with systems outside its own text generation.

A tool may:

Search the web
Read a file
Query a database
Run a calculation
Execute a terminal command
Inspect a repository
Render a chart
Parse a PDF
Update a CMS
Access a local knowledge index

When a model uses a calculator, the arithmetic result comes from the calculator rather than from linguistic prediction. When it searches a project, the filenames come from the filesystem rather than memory. When it queries a building-code corpus, the passages come from that corpus.

Tool use can make an answer more grounded, but only when the tool is appropriate and its result is interpreted correctly.

A model may still choose the wrong tool, construct a poor query, overlook an error, or overstate what the tool proved. Good agent design includes checks around tool selection and output.

Layer five: the agent or harness

An agent is the layer that organizes models, context, retrieval, tools, memory, and actions around a goal.

The term is frequently overused. A single chatbot response is not necessarily an agentic workflow. The useful distinction is whether the system can manage a sequence of decisions and actions.

An agent might:

Inspect the task.
Determine what information is missing.
Search relevant files.
Retrieve external sources.
Form a plan.
Execute part of the plan.
Test the result.
Revise after failure.
Preserve the final artifact.
Report what was verified and what remains uncertain.

The harness is the environment that makes this behavior possible. It controls available tools, permissions, memory, workflows, and execution rules.

A powerful model inside a weak harness may remain a clever conversationalist. A good harness turns model capability into disciplined work.

From “answer machine” to “doing system”

The easiest way to misunderstand AI is to treat it as an oracle.

An oracle is expected to know the answer. A useful agent is expected to manage uncertainty while moving a task forward.

Consider these two responses.

The first says:

This application probably has a configuration error. Check the environment variables.

The second says:

I inspected the configuration loader and the deployment manifest. The application expects DATABASE_URL, but the production environment defines DB_URL. The failing test reproduces the mismatch. I have not changed production; here is the one-line correction and the test result.

The second response is better not because it sounds more technical, but because it exposes its evidence and boundaries.

It tells you:

What was inspected
What mismatch was found
How the hypothesis was tested
What was not changed
What action is proposed

This is the behavior you should encourage.

Ask AI to show its work at the level of evidence, not to reveal private internal reasoning. Useful evidence includes sources, commands, tests, document excerpts, assumptions, and unresolved questions.

Installing and starting Expert AI

Expert AI is the lightweight CLI in your existing terminal. It is separate from the dedicated Expert AI Terminal Pro product.

The simple rule is:

If you type x or launch expert-ai inside your normal terminal, you are using Expert AI.

According to the current Expert AI Unlimited documentation, the native installers support Windows and macOS and configure their own private runtime. The installer is intended to avoid manual Node.js, Python, Docker, API-key, and environment-variable setup.

The basic flow is:

Download the installer for your operating system.
Run it.
Enter the email connected to your SSV.ASIA account.
Confirm the browser sign-in.
Start the terminal and type your first prompt.

If you prefer npm and already maintain a Node.js environment, the package can also be installed with:

npm install -g expert-ai

You can then launch the interactive interface:

expert-ai

or:

The exact installer behavior and available commands can change as the software develops, so use the current documentation as the operational reference.

A note about unsigned installers

The current documentation states that version 0.2.2 is not yet Developer ID or Authenticode signed. Your operating system may therefore display an unknown-developer or reputation warning.

Do not develop the habit of bypassing security warnings casually.

Before running any unsigned software:

Confirm that it came from the official download page.
Check the publisher’s current release notes.
Verify a checksum when one is provided.
Scan the file with your operating system’s security tools.
Do not run an installer forwarded through an unknown message or mirror.

Software can be legitimate and unsigned, particularly during an early release. The warning still deserves attention.

Your first prompt

A poor first prompt is:

What can you do?

It will produce a broad answer, but it teaches you very little about working with your own material.

A better first prompt gives the AI a small, real task:

Inspect this folder without changing anything. Explain what it contains, identify the three most important files, and tell me what you would examine next.

This prompt is useful because it defines:

Scope: this folder
Permission: read-only
Output: explanation and prioritization
Boundary: do not change anything
Next step: recommend further inspection

If the current folder contains no meaningful project, create a small practice folder with two or three documents. Use non-sensitive material. Then ask:

Read the documents in this folder. Summarize each one in two sentences, identify any contradictions, and cite the filename supporting every claim.

The goal is not to make the AI perform an impressive trick. It is to observe the relationship between instruction, evidence, and result.

Ask yourself:

Did it read every file?
Did it cite the correct file?
Did it invent a contradiction?
Did it distinguish fact from interpretation?
Did it respect the instruction not to edit anything?

That small exercise teaches more than a long list of features.

Prompting is specification, not incantation

There are no magic words that unlock perfect AI.

Good prompting is closer to writing a brief for an intelligent colleague. The brief should communicate the desired outcome, relevant context, constraints, and standard of evidence.

A practical prompt has five parts:

Goal
Context
Constraints
Method
Deliverable

Here is a weak prompt:

Research sustainable concrete.

Here is a stronger version:

Prepare a technical briefing on lower-carbon concrete options for a mid-rise institutional building in North India. Compare supplementary cementitious materials, mix-design implications, supply constraints, embodied-carbon effects, and relevant durability considerations. Use primary or authoritative sources where possible. Separate verified findings from general recommendations, cite every quantitative claim, and finish with a decision matrix for an architect at concept stage.

The improved prompt does not merely contain more words. It resolves important ambiguities.

Goal

What decision or outcome should the work support?

“Research sustainable concrete” describes a topic. “Prepare a briefing that supports material selection for a mid-rise institutional building” describes a purpose.

Models perform better when they know why an answer exists.

Context

What situation changes the answer?

Climate, location, audience, budget, project stage, file structure, software stack, and intended use can all matter.

A beginner’s explanation of a transformer should differ from an explanation written for a machine-learning engineer. A fire-safety answer for an assembly building should not be generalized from a residential example.

Constraints

What must the AI avoid or preserve?

Useful constraints include:

Do not edit files.
Use only the supplied documents.
Do not cite secondary summaries.
Preserve the existing public API.
Keep the final draft under 1,000 words.
Do not include confidential names.
Stop before publishing.
Ask before any destructive operation.

Constraints are not signs of distrust. They are part of a professional brief.

Method

Should the AI compare sources, run tests, inspect files, retrieve citations, or review its own draft?

For example:

First inspect the relevant files, then describe your proposed changes. After implementation, run the existing tests and report any failures.

This creates a sequence and a quality gate.

Deliverable

What should the result look like?

You might request:

A Markdown report
A table
A patch
A checklist
A slide outline
A cited research brief
A revised document
A risk register
A decision memo

Without a defined deliverable, the model must guess how to package the work.

Five prompting habits that improve almost everything

1. Give the AI a real object

“Improve my writing” is abstract.

“Edit this introduction for clarity while preserving my argument, sentence rhythm, and first-person voice” gives the AI an object and a standard.

Point to the file, passage, dataset, codebase, or decision.

2. Separate facts from preferences

Facts can be checked. Preferences must be communicated.

For example:

The audience is architecture students. I prefer direct prose, short paragraphs, and minimal marketing language.

The first sentence establishes context. The second defines taste.

AI cannot infer your aesthetic reliably from the word “professional.”

3. Ask for uncertainty to remain visible

A model is often rewarded for producing a complete answer, even when the evidence is incomplete.

Counter that tendency explicitly:

If the sources do not support a conclusion, say so. Do not fill gaps with plausible assumptions. Label any inference.

This does not eliminate hallucinations, but it improves the contract.

4. Use examples selectively

One good example can teach a pattern more effectively than a page of adjectives.

Instead of:

Make the headings exciting, sophisticated, elegant, intelligent, modern, and not generic.

Write:

Prefer headings such as “The model is not the system” over generic headings such as “Understanding AI.”

Examples define the target.

5. Ask for verification appropriate to the task

For code:

Run the tests and show the relevant result.

For research:

Link every major claim to a source and identify which sources are primary.

For document editing:

Provide a short change summary and confirm that names, dates, and numerical values were preserved.

For publishing:

Preview the final result and verify that links, headings, images, metadata, and mobile layout work.

“Double-check it” is weaker than naming what should be checked.

AI basics: tokens, context, temperature, and models

You do not need deep machine-learning knowledge to use AI well, but four concepts are worth understanding.

Tokens

Models do not process text exactly as humans see words. They break text into units called tokens.

A token may be:

A whole short word
Part of a longer word
Punctuation
A number fragment
A space combined with text
A piece of code

Token counts vary by language and content. Code, tables, uncommon names, and some writing systems may tokenize differently from ordinary English prose.

Tokens matter because AI services often measure input and output by token usage. They also determine how much material fits inside the context window.

A large monthly token allowance sounds abstract. Translate it into your own work:

How many documents do you analyze?
How long are your conversations?
Do you process codebases or short prompts?
Do you use premium models for every task?
Do automated workflows repeat requests?

Do not equate a large token pool with infinite autonomous compute. A human working interactively and a software loop running continuously have very different consumption patterns.

The Unlimited AI plan currently describes separate free and Pro token pools with a monthly refresh. Check the live product page for current allowances, routing, terms, and pricing rather than relying on an old article.

Context windows

The context window is the working material a model can consider during a request.

It includes your instructions, conversation history, retrieved evidence, and sometimes tool results.

When a conversation becomes very long, a system may summarize older material or drop less relevant parts. That can cause forgotten constraints or inconsistent answers.

For long projects:

Keep authoritative instructions in a project file.
Store decisions in durable notes.
Use clear filenames.
Record accepted terminology.
Begin major phases with a concise context summary.
Ask the agent to inspect the source of truth instead of relying on conversational memory.

Conversation is useful for collaboration. Files are better for durable state.

Temperature and variability

Some model interfaces expose a setting called temperature. Higher values generally allow more variation; lower values generally make output more conservative.

Temperature is not a truth control.

A low-temperature answer can still be wrong. A high-temperature answer can still be accurate. The setting influences sampling behavior, not access to evidence.

For factual work, retrieval and verification matter more than merely reducing variability.

Different models have different strengths

There is no universally best model for every task.

Models differ in:

Reasoning behavior
Coding ability
Writing style
Speed
Cost
Context capacity
Tool use
Multilingual ability
Image or audio support
Availability
Safety behavior

Model routing can send different requests to different models or service lanes. The user may choose a model explicitly, or the system may select one based on the task and plan.

The useful question is not “Which model wins?” It is:

Which model, context, tools, and verification process are appropriate for this task?

A fast inexpensive model may be ideal for classifying files. A more capable model may be justified for a difficult architecture review. A local model may be preferable when privacy or connectivity matters.

Model choice is one component of system design.

Retrieval: how AI answers from your knowledge

Imagine that your Obsidian vault contains ten thousand notes.

You ask:

What have I already written about passive cooling in hot-dry climates?

Pasting the entire vault into a prompt would be wasteful and probably counterproductive. A retrieval system searches the vault and selects likely matches.

A simple search looks for literal words. More advanced retrieval may use embeddings—numerical representations that place semantically related text closer together.

This allows a query for “reducing heat gain” to find a passage about “solar-load mitigation,” even when the wording differs.

The ideal retrieval pipeline may combine:

Exact keyword search
Full-text search
Semantic similarity
Metadata filters
Date or folder constraints
Re-ranking
Citation tracking

Retrieval is especially valuable for personal knowledge management because your archive contains information unavailable in a public model.

Your notes may include:

Project decisions
Research excerpts
Client constraints
Design observations
Meeting records
Draft arguments
Technical references
Lessons from previous failures

When AI can retrieve this material locally, your vault stops behaving like a passive storage cabinet. It becomes an active memory system.

But retrieval quality depends on information architecture.

Clear titles help. Useful metadata helps. One subject per note often helps. Consistent terminology helps. Links between related notes help. A folder full of documents named final-v2-new-revised.md makes both human and machine retrieval harder.

AI does not remove the need for knowledge organization. It increases the value of doing it well.

Grounded answers and provenance

A polished answer can be dangerous when its evidence is invisible.

This is especially true in architecture, engineering, construction, medicine, law, finance, security, and scientific research. In these fields, an answer may influence a consequential decision.

A grounded answer should let you trace important claims back to sources.

Suppose you ask:

What is the minimum required staircase width?

A weak response provides one number without context.

A better response asks or establishes:

Which jurisdiction?
Which building code and edition?
Which occupancy?
Which building height?
Is this a main stair, service stair, or fire escape?
Is the question about minimum clear width?
Are local amendments relevant?

Then it retrieves the applicable clause or table and identifies the source.

Even then, the AI should not pretend to replace professional judgment or the official publication.

For compliance work:

Use AI to locate and explain.
Inspect the cited clause yourself.
Confirm the edition and applicability.
Check amendments and authority requirements.
Record the basis of the final decision.

This is not a limitation unique to AI. Human summaries, guidebooks, search results, and remembered rules can also be wrong. AI makes fluent synthesis easier, which makes verification more—not less—important.

Four useful evidence labels

A rigorous workflow can classify claims as:

Verified: directly checked against an appropriate source or test
Supported: consistent with available evidence, but not independently reproduced
Inferred: a reasoned conclusion rather than an explicit source statement
Blocked: verification could not be completed

These labels are more honest than smoothing every statement into the same confident voice.

AI for architects and engineers

Architecture, engineering, and construction offer unusually rich opportunities for grounded AI because the work is document-heavy, multidisciplinary, and dependent on precedent.

A practitioner may need to navigate:

Building codes
Standards
Specifications
Research papers
Material data
Climate analysis
Design briefs
Schedules
Drawings
Contracts
Bills of quantities
Meeting records
Product literature
Historical precedents

A generic language model can explain concepts, but specialized retrieval becomes valuable when the answer must connect to an actual document.

The AEC knowledge workflow in Expert AI is designed around cited retrieval from a curated corpus. The local documentation describes material spanning codes and standards, research, curricula, architects, buildings, and precedents.

The most important skill is learning to ask in the language of the source.

Ask like an index entry

A conversational query may be:

Can you tell me how buildings stay cool in hot places?

A retrieval-oriented query is:

passive cooling strategies hot-dry climate courtyard ventilation thermal mass

The second form resembles a chapter heading or set of index terms. It gives the search engine several strong anchors.

For code research, name the code:

NBC 2016 minimum staircase width residential buildings

Better still, include a known clause or table:

IS 456 Table 16 nominal cover exposure conditions

Translate site language into code language

The words used in practice may differ from the words used in formal documents.

Everyday expression	Formal search language
Escape route	Means of escape, travel distance
Coastal conditions	Severe or very severe exposure
Concrete cover	Nominal cover to reinforcement
FSI	Floor area ratio
Setback	Open spaces
Fireproof rating	Fire resistance
Earthquake design	Seismic design, zone factor
Toilets required	Sanitation requirements, water-closets

This is not just an AEC lesson. Every specialized corpus has its own vocabulary.

The better your query matches the language of the source, the more precise retrieval becomes.

Ask one question at a time

A query that combines concrete cover, parking requirements, stair widths, and façade fire performance forces the search system to split its attention.

Ask four focused questions.

This also produces a clearer evidence trail. Each answer can cite the specific document relevant to its own issue.

Chase references

Technical documents refer to their own clauses, figures, annexures, and tables. If an answer mentions a table without retrieving its values, ask for that table explicitly.

Research is often iterative:

Find the governing section.
Identify a referenced clause.
Retrieve the clause.
Compare exceptions.
Confirm applicability.

AI can accelerate this chain, but it should not collapse the chain into an unsupported conclusion.

What makes an AI workflow agentic?

“Agent” is now attached to almost every AI feature. Use a stricter test.

A workflow becomes meaningfully agentic when the system can pursue an outcome through multiple steps, observe results, and adjust its actions.

Consider a research task:

Investigate whether a proposed façade material is appropriate for a coastal institutional project.

A simple chatbot may produce a general essay.

An agentic workflow might:

Clarify climate, location, exposure, building type, and performance goals.
Search local project files.
Retrieve relevant standards.
Find manufacturer data.
Search recent technical research.
Compare durability, maintenance, fire behavior, carbon, cost, and availability.
Flag conflicts between sources.
Identify missing test data.
Produce a decision matrix.
Store citations and provenance beside the report.
Ask for approval before turning the recommendation into a specification.

The value is not that the system used many tools. The value is that the sequence matches the structure of the decision.

More steps do not automatically mean more intelligence. A badly designed agent can waste time by repeatedly searching the same material or performing unnecessary actions.

The best agent is often the smallest workflow that reliably completes the job.

Research workflows in Expert AI

Expert AI’s documented command surface includes workflows for research, comparison, review, coding, local knowledge, and offline use. Commands can evolve, so consult the live documentation for the current syntax.

The important concepts are more durable than the exact names.

Deep research

A deep-research workflow should go beyond collecting search results.

It should:

Define the question
Identify credible source types
Search broadly enough to find disagreement
Prefer primary evidence
Record publication dates
Separate source claims from synthesis
Preserve citations
Identify uncertainty
Produce a durable report

A useful request might be:

Run deep research on the adoption of mass-timber structural systems for mid-rise buildings in hot and humid climates. Focus on durability, moisture risk, fire regulation, supply chains, embodied carbon, and built precedents. Prefer standards, peer-reviewed papers, and official case studies. Separate global findings from evidence applicable to India.

Literature review

A literature review is not a list of paper summaries.

It should map:

Major research themes
Competing methods
Areas of agreement
Important disagreements
Dataset or measurement limitations
Research gaps
Seminal and recent work

Ask the system to explain its inclusion criteria. Otherwise, a literature review may simply reflect whichever papers were easiest to retrieve.

Paper audit

A paper may make claims that its published code does not fully reproduce.

A paper-audit workflow can compare:

Method described in the paper
Public implementation
Configuration files
Dataset handling
Evaluation metrics
Reported results
Missing dependencies
Unstated preprocessing
Reproducibility risks

This is a good example of AI moving beyond summarization. The goal is not to explain what the paper says. It is to compare the claim with an inspectable artifact.

Source comparison

When sources disagree, do not ask the model to choose a winner immediately.

Ask for a matrix:

Question	Source A	Source B	Source C	Agreement	Confidence

This makes disagreement visible.

Differences may arise from:

Different dates
Different jurisdictions
Different definitions
Different datasets
Different methods
Different commercial incentives
Genuine scientific uncertainty

A good synthesis explains the reason for disagreement when the evidence permits it.

Peer review

A review workflow should challenge a draft rather than congratulate it.

Ask it to identify:

Unsupported claims
Missing counterarguments
Ambiguous terminology
Methodological weaknesses
Citation gaps
Overgeneralization
Structural problems
Likely expert objections

Then ask for a revision plan ranked by severity.

Replication and autonomous experimentation

For a measurable technical task, an agent can establish a baseline, try changes, run tests, and compare results.

The loop is:

Define a metric.
Measure the baseline.
Propose one change.
Execute it.
Measure again.
Keep or discard the change.
Record the result.
Repeat within agreed limits.

This is much stronger than asking AI, “How can I optimize this?”

The agent must prove improvement against the metric.

Working with files without losing control

File access is one of the most useful AI-terminal capabilities. It is also where beginners need clear habits.

Begin read-only

For an unfamiliar project, start with:

Inspect this directory without changing anything. Explain its structure, identify important files, and note any risks or ambiguities.

This lets the agent form a map before acting.

Ask for a plan when changes are broad

For a small typo, direct editing is reasonable.

For a change touching many files, ask the agent to explain:

Which files it expects to modify
Why each file is involved
How it will verify the result
Whether any migration or compatibility risk exists

You do not need a ceremonial plan for every task. Planning becomes valuable when the cost of misunderstanding is high.

Use version control

If a folder contains code or important text, version control gives you a history of changes and a way to inspect differences.

The agent should not use version control as an excuse for reckless edits. It is a recovery mechanism and review surface.

Before a consequential change:

Know the current state.
Preserve unrelated work.
Review the diff.
Run relevant checks.
Commit intentionally.

Keep backups of published content

Before changing a live CMS post, preserve:

The current content
Metadata
Publication status
Slug
Tags
Feature image
Update timestamp

This makes rollback possible if formatting or conversion fails.

Treat deletion differently

Reading and creating are generally easier to recover from than deletion and overwriting.

For destructive actions, the agent should resolve the exact target, explain the scope, and confirm when appropriate.

“Clean up my project” is not sufficient authorization to remove broad directories.

Privacy: local-first does not mean magically private

Privacy claims deserve precise language.

A local-first application may keep files, indexes, and session state on your machine. That is useful. But if a request is sent to a cloud model, the prompt and selected context leave the machine for inference.

Ask four questions:

Where are my files stored?
Which parts of them are sent to a model?
Which provider receives the request?
What retention and training policies apply?

A zero-retention gateway may avoid storing prompts after processing. That is different from offline inference, where the prompt never leaves the machine.

Local retrieval

A local search index can find notes without sending the full vault to a remote service. Only selected passages may be included in a model request.

This reduces exposure but does not make the final request offline.

Offline models

An offline workflow runs inference on local hardware.

Advantages include:

Data remains local
No network dependency
Predictable availability
Greater control over models and logs

Tradeoffs include:

Hardware requirements
Slower inference
Smaller or less capable models
Setup complexity
Local security responsibilities

Offline AI is not automatically safer in every respect. A compromised machine can still expose local data. Privacy is a system property, not a marketing adjective.

Sensitive work

Before using AI with confidential material:

Understand organizational policy.
Remove unnecessary personal data.
Limit the files placed in scope.
Prefer local retrieval.
Use approved providers.
Avoid secrets in prompts.
Check retention settings.
Preserve an audit trail for consequential decisions.

Convenience should not silently expand the data boundary.

Model Context Protocol: tools as a standard interface

The Model Context Protocol, or MCP, is an open protocol for connecting AI applications to external tools and data sources.

A useful analogy is USB.

Before common hardware interfaces, every device needed a different connector. A shared protocol allows a host application to discover and use compatible capabilities through a consistent pattern.

An MCP server might provide tools for:

Searching a knowledge base
Reading project records
Querying a database
Retrieving building-code passages
Accessing a design system
Managing files
Inspecting analytics

MCP does not make every connected tool trustworthy. It standardizes the interface.

The host still needs to manage:

Authentication
Permissions
Tool descriptions
User approval
Error handling
Data exposure
Audit logs

A poorly described tool can be misused. A broadly permissioned tool can create unnecessary risk.

The principle is least privilege: give the AI only the capability required for the task.

Terminal AI versus ChatGPT

This is not a contest with one universal winner.

Use a chat interface when you want:

A quick conversation
General explanations
Brainstorming
Casual image or voice interaction
A clean environment separated from local files
Minimal setup

Use a terminal agent when you want:

Direct work on a project
File-aware analysis
Repeatable workflows
Code execution
Tests
Local knowledge retrieval
Automation
Durable artifacts
Tool orchestration

Often the best approach is to use both.

You might explore an idea conversationally, then move into the terminal when the idea becomes a project with files, evidence, and actions.

The distinction is not “beginner versus expert.” It is conversation versus work surface.

Expert AI and Expert AI Terminal Pro

The product names are similar, so the distinction should remain explicit.

Expert AI

Expert AI is the lightweight, free-to-start CLI designed to run inside your existing terminal. It uses the x or expert-ai command and provides managed access through SSV.ASIA.

It is intended for people who want a quick route into terminal-based AI without assembling providers, runtimes, and configuration manually.

Expert AI Terminal Pro

Expert AI Terminal Pro is a separate professional product. It is described as a larger, locally installed or portable agentic harness with capabilities such as provider authentication, research workflows, subagents, persistent memory, document tools, knowledge-vault search, scheduling, previews, and broader local control.

It is not an automatic upgrade that appears because you typed x. It is purchased and installed intentionally.

The simplest distinction is:

Expert AI: lightweight managed CLI in your existing terminal
Expert AI Terminal Pro: dedicated professional harness and portable environment

Always consult the current product documentation before purchasing because features, pricing, installation, and release status can change.

Your first serious workflow: turn a folder into a research brief

The following exercise is designed to teach the complete pattern without requiring code.

Choose a folder containing three to ten non-sensitive documents about one subject. These may be notes, articles, Markdown files, PDFs, or reports.

Step 1: establish scope

Start the terminal in that folder or point the agent to it.

Prompt:

Work only inside this folder. Begin read-only. List the available documents, their formats, and their approximate roles. Do not summarize them yet.

Why this matters: you are checking whether the agent sees the expected material.

Step 2: define the question

A folder is not a research question.

Prompt:

I want to understand the strongest evidence, disagreements, and unanswered questions in these documents concerning [your subject]. Before researching, rewrite that objective as one precise question and three subquestions.

Review the proposed questions. Correct them if necessary.

Step 3: inspect the evidence

Prompt:

Read the documents relevant to the approved questions. Create an evidence table with the document name, date if available, main claim, supporting evidence, limitations, and relevance. Quote sparingly and preserve page or section references when available.

The table forces structure and exposes weak sources.

Step 4: identify contradictions

Prompt:

Compare the documents. Identify direct contradictions, differences in definition, differences caused by publication date, and conclusions that appear compatible despite different wording. Do not declare a winner unless the evidence supports it.

This teaches the model not to flatten disagreement.

Step 5: find gaps

Prompt:

List the questions these documents cannot answer. For each gap, name the type of source needed: standard, primary research, dataset, official guidance, manufacturer test, or expert judgment.

Now you have a research agenda rather than a decorative summary.

Step 6: perform external research

If web access is available:

Search for authoritative sources that address the identified gaps. Prefer primary research, official standards, government publications, and first-party technical documentation. Record the URL, publisher, publication date, and the exact gap addressed.

Do not ask the AI merely to “find more sources.” Tie each source to a known gap.

Step 7: write the brief

Prompt:

Produce a decision-oriented research brief. Include an executive summary, scope, evidence, disagreements, limitations, recommendations, unresolved questions, and references. Cite every consequential claim. Clearly label verified facts, synthesis, and inference.

Step 8: review the brief adversarially

Prompt:

Review this brief as a skeptical domain expert. Identify unsupported claims, missing counterarguments, weak sources, ambiguous language, and conclusions stronger than the evidence. Rank issues by severity and propose corrections.

Step 9: revise

Prompt:

Apply the review findings that improve accuracy. Do not conceal unresolved uncertainty. Add a short methodology note explaining what was searched and what could not be verified.

Step 10: preserve the artifact

Save:

The final brief
The source table
The review
A provenance note
The original documents
The date of research

You have now used AI as a research system rather than an answer generator.

A practical 60-minute learning plan

Your first hour should produce something useful.

Minutes 0–10: orientation

Open the terminal.
Start Expert AI.
Ask it to explain the current directory without making changes.
Confirm that the files it names really exist.
Ask what it can and cannot access.

Your objective is to understand scope and permission.

Minutes 10–20: learn prompting through contrast

Give the AI one vague prompt and observe the result:

Summarize this project.

Then improve it:

Explain this project to an intelligent beginner. Start with its purpose, then its folder structure, then the normal workflow. Cite filenames for every project-specific statement. End with five questions I should ask before changing anything.

Compare the two answers.

Notice how purpose, audience, evidence, and deliverable change the result.

Minutes 20–30: use local context

Select one real document.

Ask:

Summarize the argument of this document in five points. Then identify assumptions, unanswered questions, and passages that need evidence. Do not rewrite it.

You are using AI as a reader and critic, not as an automatic editor.

Minutes 30–40: request a bounded change

Ask:

Create a revised copy with clearer headings and shorter paragraphs. Preserve every name, date, number, link, and technical claim. Do not overwrite the original. Provide a change summary.

Compare the original and revision.

Minutes 40–50: test research grounding

Ask one factual question about the document set:

Answer using only these files. Cite the filename and section supporting each claim. If the answer is unavailable, say so.

Then ask a question the files cannot answer.

A trustworthy response should acknowledge the gap.

Minutes 50–60: produce an artifact

Choose one:

A research brief
A glossary
A checklist
A project map
A decision table
A study guide
A risk register
A list of contradictions
A next-step plan

Ask the AI to save it as a new Markdown file with a descriptive name.

Finish by asking:

Report exactly what you read, what you created, what you changed, and what remains uncertain.

At the end of the hour, you should have both a useful artifact and a clearer understanding of the system.

Ten prompts worth keeping

Understand a folder

Inspect this folder read-only. Explain its purpose, structure, important files, and likely workflow. Cite filenames and distinguish evidence from inference.

Understand a document

Explain this document to a beginner without removing technical precision. Define unfamiliar terms, summarize the argument, and identify assumptions and open questions.

Improve writing

Edit this draft for clarity, structure, and economy. Preserve my argument and voice. Do not change factual claims unless you flag the proposed correction separately.

Compare sources

Compare these sources in a matrix. Show agreements, disagreements, definitions, evidence quality, publication date, and remaining uncertainty.

Research a question

Research this question using primary and authoritative sources. Cite consequential claims, include publication dates, and label any inference.

Review code

Inspect this code without editing it. Explain what it does, identify correctness and security risks, and rank findings by severity with file references.

Implement safely

Implement this change with the smallest reasonable scope. Preserve existing behavior outside the request, run relevant tests, and summarize files changed and verification performed.

Search an AEC corpus

Search for [code and edition] [formal topic] [building type or condition]. Return the relevant clause or table reference, source excerpt, applicability conditions, and issues requiring professional verification.

Challenge an argument

Act as a skeptical peer reviewer. Identify unsupported claims, missing counterarguments, ambiguous language, and conclusions stronger than the evidence. Provide a prioritized revision plan.

Close a session

Create a concise session log containing the objective, work completed, files changed, evidence checked, unresolved questions, and safest next step.

Common mistakes—and what to do instead

Mistake: treating fluency as accuracy

A well-written answer feels complete.

Instead, inspect evidence. Ask where important claims came from.

Mistake: uploading everything

Large context can become noisy and expensive.

Instead, retrieve relevant material and expand only when necessary.

Mistake: asking for a complete project in one sentence

The AI must invent requirements.

Instead, define the outcome, constraints, acceptance criteria, and boundaries.

Mistake: allowing edits before inspection

The agent changes symptoms without understanding structure.

Instead, begin read-only for unfamiliar projects.

Mistake: requesting “the best” without criteria

Best for what—speed, cost, quality, privacy, compatibility, or learning?

Instead, define the decision criteria.

Mistake: using AI output as an authority

The answer may synthesize evidence, but it is not the governing standard.

Instead, verify consequential decisions against authoritative sources.

Mistake: demanding certainty

When uncertainty is punished, the model may manufacture confidence.

Instead, explicitly permit “unknown,” “unverified,” and “insufficient evidence.”

Mistake: confusing automation with judgment

An agent can execute a process efficiently while optimizing the wrong objective.

Instead, keep human review at consequential decision points.

Mistake: failing to preserve state

Important decisions live only inside a long conversation.

Instead, write decisions, assumptions, and results into durable project files.

Mistake: believing one model should do everything

Tasks differ.

Instead, match the model and tools to the job.

What “expert AI” should mean

The phrase should not mean an AI that claims expertise.

A credible expert system demonstrates discipline.

It should:

Retrieve domain-relevant evidence
Use appropriate terminology
Cite sources
Expose uncertainty
Respect jurisdiction and context
Ask when applicability is unclear
Separate quotation from interpretation
Preserve an audit trail
Use tools appropriate to the task
Avoid substituting itself for licensed judgment

Expertise is not verbosity. It is reliable discrimination: knowing which details matter, which evidence governs, and where the boundary of confidence lies.

In a professional setting, the AI’s most valuable response may be:

The available documents do not establish this. We need the current jurisdictional amendment and the manufacturer’s tested assembly report before deciding.

That answer is less spectacular than an instant recommendation. It is also more useful.

The deeper shift: from prompts to systems

Most people begin with prompts because prompts are visible.

But sustained value comes from systems.

A dependable AI system includes:

Well-organized source material
Clear permissions
Appropriate models
Retrieval
Tools
Repeatable workflows
Verification
Durable outputs
Human decision points
Feedback from mistakes

Prompt skill still matters. Yet even the best prompt cannot compensate for missing evidence, an obsolete corpus, excessive permissions, or a workflow without tests.

The mature question is not:

How do I make the model give me the answer I want?

It is:

How do I design a process that produces an answer I can inspect, improve, and trust appropriately?

That is the difference between using AI for novelty and using it for serious work.

Final perspective

Your first hour with an AI terminal is not about memorizing commands.

It is about learning a new relationship with computation.

You describe an outcome. The system inspects context, retrieves knowledge, uses tools, and proposes or performs actions. You examine the evidence, correct the direction, and decide what deserves trust.

The terminal makes that relationship unusually visible. Files are real. Commands leave traces. Tests pass or fail. Sources can be opened. Drafts can be compared. Claims can be challenged.

The best AI workflow is not one where the machine acts alone. It is one where human judgment and machine execution strengthen each other.

The human contributes:

Purpose
Taste
Context
Ethics
Responsibility
Domain judgment
The ability to recognize when a technically valid answer is inappropriate

The system contributes:

Speed
Breadth
Retrieval
Repetition
Pattern recognition
Tool coordination
The ability to work across more material than a person can comfortably hold at once

Neither side is sufficient for every problem.

Together, with clear boundaries and visible evidence, they can produce work that is faster without becoming careless, broader without becoming shallow, and more ambitious without becoming unaccountable.

Open the terminal.

Begin with a real folder.

Ask for a map before a change.

Ask for evidence before confidence.

Then make something worth keeping.

Continue learning

Product features, pricing, token allowances, model routes, and release status may change. Refer to the live documentation for current operational information.