From Chat
to Agents

This session introduces ways AI could support work at the Manufacturing Solutions Center, from reading grant announcements to preparing report drafts. The goal is to build enough familiarity to identify one or two useful experiments. No prior AI experience is required. The examples use public information and fictional project and laboratory records, so they can illustrate the work without exposing customer material.

Throughout the presentation, the person using the tool remains responsible for checking its output and deciding what is appropriate to use.

The presentation begins with a short explanation of agents, followed by grant-screening and laboratory-report examples. Those examples provide a basis for recognizing similar tasks in everyday work. The walkthrough then explains how to give instructions, supply files, and inspect the results.

Platform selection and confidentiality are part of deciding whether a useful example can become a practical workplace tool. The final discussion focuses on defining small experiments with clear inputs, an expected result, and someone qualified to review the work.

These questions help you consider your own experience with AI. Occasional questions, regular use, and delegating a task are different starting points, and each provides something to build on. A task might be turning notes into a draft, comparing several documents, or checking whether a report includes required information.

You can begin with a single conversation and a small piece of work. The useful next step depends on what you need help with and how confidently you can judge the result.

Asking a question is a useful introduction to AI. In the slide's example, an explanation of measurement-uncertainty documentation could help orient someone before reading the applicable requirements. That answer still needs to be checked against the relevant authoritative documents and versions. A further step is to provide an approved procedure and ask for a source-linked list of questions or possible gaps.

This moves from a general explanation toward a work product. A chat can also draft and organize material, so the distinction is the task and access you provide, rather than the appearance of the conversation window.

AI tools can help produce work through a sequence of actions, including reading files, organizing information, and preparing drafts. Starting small makes it easier to understand where that help is reliable and where it creates extra checking. A suitable first task has an output you recognize and mistakes you know how to find.

Human responsibility remains central: a fluent answer, completed checklist, or polished report does not establish that the underlying facts are correct. Customer-facing work still needs the appropriate review and approval.

An agent uses available tools to work through a task, observing the result of one step before choosing another. For example, it might read a grant announcement, compare the requirements with a project brief, and create a checklist of missing information. Its capabilities depend on the application, the tools available, and the access granted.

Define the goal, relevant sources, and boundaries before it begins. Review the resulting work and retain approval over consequential actions, such as sending information or changing records. Completing several steps does not guarantee that the result is correct.

The grant example pairs NSF's Advanced Technological Education announcement with a fictional technician-training project. The requested output is a screening table that connects each requirement to an official source, identifies supporting information in the brief, and marks gaps or apparent mismatches. The fictional brief leaves course credit status and faculty leadership unresolved, making these useful issues to investigate. The exercise illustrates early screening, not a finding that MSC qualifies. As checked September 7, 2026, the NSF program page listed an October 1, 2026 deadline at 5 p.m. in the submitting organization's local time.

The program page and full solicitation provide the authoritative details. The demo packet contains the fictional brief and prompt. A useful screening result may identify reasons to pause before investing in an application.

The laboratory example uses fictional textile measurements, an illustrative report template, and a deliberately flawed draft. The task is to compare the draft with those sources, list discrepancies, and produce a corrected version for qualified review. One force reading has been copied incorrectly, a missing dimensional-change reading has been filled in without evidence, and the draft makes unsupported conclusions. The example demonstrates both document checking and drafting while keeping the original records intact.

All measurements, methods, and organizations are invented; the template does not represent MSC's reporting format or an accredited method. The sample files and instructions allow the exercise to be repeated. The prepared errors are known checks, not a claim that an AI will detect every problem.

In the fictional source records, sample B's third breaking-force reading is 389 N; the flawed draft changes it to 398 N. The correct mean is 389.0 N, which does not meet the fictional customer's mean-force criterion of at least 400 N. A subtler error appears in dimensional change: the two recorded readings are -3.0% and -3.2%, while the third is missing.

Their mean is -3.1%, which is also the value invented for the missing reading. The displayed mean therefore looks correct even though the evidence has been altered. Review must cover source values, units, missing entries, and the basis for conclusions. No dimensional-change acceptance criterion was supplied, so a pass/fail conclusion is unsupported.

Useful candidates often involve gathering information, checking completeness, or turning rough material into a form someone else can use. Grant preparation may involve comparing instructions with an application. Laboratory work may involve checking a draft against recorded results. Other departments may repeatedly answer similar questions or reformat the same approved information.

The examples are starting points for recognizing that pattern in your own work. Describe the current task before choosing a tool: where the information comes from, what you produce, and which parts require judgment. Your process may differ substantially from the fictional demonstrations.

The walkthrough follows the same sequence as the demonstrations: enter a task, supply its sources, inspect the work, and refine the result. The important controls are the conversation input, file attachment or access controls, output viewer, and relevant settings. Keep the original material available while reviewing a generated document so you can compare them directly.

Menu names and available features vary by product, plan, and settings. Understanding what you are giving the tool access to, and what it is producing, matters more than memorizing every button.

A useful request explains the task, the intended reader, and what the finished result should look like. An example or source file reduces the amount the AI has to infer. If an option or answer is unclear, ask it to explain before deciding. You can also ask it to interview you one question at a time to discover missing context.

For example, a report-drafting task might require clarification about the audience, required sections, and claims that need supporting evidence. Review and correction are part of the process; use them to improve both the output and the instructions for the next attempt.

File access lets an AI use source documents directly rather than relying on a description of their contents. Begin with copies of the specific files needed for a task, and ask it to create a new draft while preserving the originals. Inspect the output against those sources, especially where it contains numbers, conclusions, or information it has combined across documents.

Today's examples can be performed with prepared files without connecting email or operational systems. Saving a draft and sending it to someone are separate actions, and external actions should remain subject to the appropriate approval.

A connector gives an AI application access to another service through the permissions granted to it. Depending on the connection, it may search documents, retrieve messages, or take actions such as creating records. Permission to read does not automatically mean permission to send. Available actions depend on the connector and its configuration. Check the actual access granted and enable only what the task requires. Use read-only access where available and approval requirements for consequential actions.

Written instructions to draft only are useful, but they do not replace permission controls. Anthropic's Microsoft 365 connector documentation, checked September 7, 2026, illustrates the distinction between read access and enabled write actions.

Claude and ChatGPT are the tools I use, and my starting preference for this group's document work is Claude, based on that experience. This is a preference rather than a permanent ranking. The college's existing Microsoft or Google arrangements, support, and approval requirements could point toward a different choice.

Compare tools using one familiar task and the same source material. Consider the quality of the result and how much work is required to correct it. A tool that fits the organization's systems and controls may be more practical than one that performs well in an isolated demonstration.

Evaluate the whole task, including preparation, correction, and review. Good output is valuable, but so is being able to use your existing files without cumbersome transfers. Usage limits, setup effort, and organizational oversight can affect whether a tool is practical. An additional subscription may introduce another place to store and manage information.

An already supported tool may reduce setup, while still needing a careful check of its included capabilities. Compare the specific plan as well as the product name, and use an actual example of your work to judge whether the trade-offs are worthwhile.

Free accounts can support learning with public or fictional material. Paid personal plans may offer additional access or higher limits, but paying does not by itself make an account suitable for confidential work. Organizational plans require their own review of terms, controls, and included features. As checked September 7, 2026, Anthropic classifies Claude Free, Pro, and Max as consumer products in its training policy.

Before purchasing, confirm the current price, the capabilities your trial needs, and the college's approval process. Capability and permission to use particular data are separate considerations.

Training policies depend on the provider, account, and plan. As checked September 7, 2026, Claude's consumer policy describes user choices and exceptions. Anthropic's commercial policy says inputs and outputs are not used for model training by default, while allowing exceptions such as voluntarily submitted feedback. A feedback report can therefore require a different decision from an ordinary work conversation, especially if it includes sensitive information.

Review the current settings and terms with the appropriate organizational reviewer before using client material. The consumer policy and commercial policy explain those distinctions. A no-training policy still leaves storage, access, and permitted use to consider.

Confidentiality includes where information is stored, how long it is retained, and who can access it. It also includes what a connected service allows the AI to do with that information. Reading, changing, and sending are distinct capabilities whose availability depends on the connection and settings. Inspect those permissions before connecting a work account.

Grant only the access needed for the task and retain approval over consequential actions. For an initial experiment, a small set of approved files may be enough. That makes the trial easier to understand and review without introducing access to a larger operational system.

Public or fictional inputs let you test the usefulness of a workflow before deciding whether it can handle real material. Removing a customer name may still leave confidential test results, designs, or identifying details. An approved account or environment must be appropriate for the information and the task, and qualified review remains necessary for customer-facing output.

Local AI may be an option to investigate, but whether information stays on a machine depends on the full setup, including any connected services. The first experiment should establish whether the drafting or checking step helps before introducing sensitive records.

The following examples cover areas Jeff identified, including grants, ISO systems, lab reporting, administration, and product development. They are possible tasks to explore, rather than validated recommendations for a particular department. The relevant question is which specific step could become easier with reliable assistance.

A broad category such as compliance is too large to test at once; a comparison between a supplied procedure and an approved checklist is more concrete. Start with the existing process and the information available, then decide whether an AI-assisted version would remove work without making review harder.

Grant work can include extracting requirements, identifying missing application material, and drafting sections from approved facts. Prior applications may provide useful source material, but their statements and format still need checking against the new opportunity. For ISO documents, a possible trial is comparing an approved procedure with the applicable checklist and flagging discrepancies with source references.

Use the correct versions and confirm permission to provide the material. The output assists the responsible person's review and cannot establish compliance by itself. Keeping sources beside the draft helps distinguish documented requirements from suggestions or unsupported statements.

A laboratory trial could begin with report completeness: checking that the sections required by a supplied template are present and that recorded results have been copied accurately. Drafting a plain-language summary is another candidate, provided the summary stays within what the results support. Interpretation, acceptance decisions, and qualified approval remain explicit parts of the process.

The fictional demo format does not establish how MSC should prepare its reports. Judge a trial by whether preparation plus review takes less effort than the current process while maintaining the required quality. A polished draft that creates more checking may not be a useful improvement.

An administrative trial might organize a copy of an approved financial export and flag entries that need attention. The responsible person would verify those entries, while QuickBooks and the college system remain the records. A marketing trial could turn an approved public announcement into a draft post or newsletter item, preserving the facts and using an appropriate tone.

Both examples focus on preparation for human review. They do not assume that an AI can or should update accounting records or publish content automatically. Repeated formatting and information assembly are possible starting points to evaluate.

AI may help turn approved development notes into a clearer process record, preserving decisions and separating unresolved questions from established information. That could support documentation in knitting product development without substituting for domain expertise. For training, approved process steps might become a draft storyboard showing what a learner should see and do at each stage.

Such a draft could support discussion of an augmented-reality training project. These are possibilities to investigate, not findings that either task is currently a problem at MSC. Specialists would need to check technical accuracy, completeness, and whether the material teaches the intended process.

Choose a recurring task you know well and describe its input, output, and source of effort. For example, the input might be meeting notes and the output a reviewed action list; the tedious step might be separating decisions from unresolved questions. A task description is enough at this stage. You do not need to design the automation or know which buttons to use.

Comparing candidates across the group can also reveal repeated requests or handoffs that affect several roles. Larger ideas can be explored later, once a small example makes the possibilities and limitations easier to judge.

Data approval and the consequences of error come first. Convenience or potential time savings cannot compensate for unacceptable data use or inadequate review. Among suitable candidates, prefer work that recurs, takes meaningful time, and can be explained with clear sources and an example of a good result.

The reviewer should know how to detect likely mistakes efficiently. This makes a small trial easier to evaluate. If checking and correction take longer than the original task, use that evidence to change the approach or choose another candidate rather than assuming every task needs automation.

A concrete trial identifies the task, the input files or information, the desired output, and the person who can review it. Define likely errors before beginning so success includes accuracy and completeness as well as speed. Compare total effort with the existing process, including setup, corrections, and review.

Any unresolved account or data approval is a prerequisite, not an assumption that the trial can proceed with real records. Public or fictional material can support an initial check. A well-defined experiment is a useful outcome even when no production automation has been built.

Explain the task in ordinary language, identify the intended reader, and provide relevant sources and an example of the desired result. State what must remain unchanged, what requires evidence, and what should be marked unknown. For the report example, that includes preserving sample IDs, measurements, and units while leaving missing readings unfilled.

Asking the AI to interview you one question at a time can expose gaps in the briefing. Asking for a plan can reveal misunderstandings before work begins. Review the result, correct it, and save the improved instructions when they prove useful.

Once a task produces useful drafts consistently, save the instructions, examples, and review checks that made it work. In tools that support skills, a skill packages reusable instructions and possibly supporting files so the task can be requested again without rebuilding the whole briefing. This does not make the result automatically reliable or remove the need for review.

Confirm which sources and context are available each time. Scheduling is a further step to consider only after the task, access, and handling of exceptions are understood. Recurring grant screening or report drafting are possibilities, not systems configured by this presentation.

Choose one or two candidates and turn each into a small, reviewable experiment. Confirm approved inputs, an appropriate account, and a reviewer before using real work material. Try an example and compare the full effort with the current process, including correction time and output quality. If essential information is missing, resolving that gap is the next step.

Working through a selected task together can help clarify the instructions and review process. The presentation and demonstration files provide a starting point; they do not record a completed implementation or decisions made by the group.

Thank you to Jeff and the MSC team for the invitation and participation. Questions about a specific task are welcome at Julio@E-String.com. A short description of what you start with, what you need to produce, and where the work becomes tedious is a useful basis for that conversation.

The contact details and feedback link on this slide are available for follow-up.