Reading a security advisory is not the same as completing the response.
MiWork Guard finds what needs attention, prioritizes the work, and revalidates the result. AI organizes the evidence and risks; administrators decide how to respond. The process becomes a trustworthy record.12
An illustration of the product's purpose, not an actual screen. Click any image in the article to view the original.
AI can increase the speed and scale at which attackers find and exploit weaknesses. Preparing for new threats must go hand in hand with basic work to reduce known risks.3
Recent incidents leave a familiar task:
On October 12, 2026, GitLab released important security fixes and urged affected users to update promptly.4
The investigation into LiteLLM's compromised October 21 release described a previously exposed administrative key that had not been revoked.5
When a vulnerability has an effective fix, applying the security update in time can close the corresponding attack path. Other issues require actions beyond updating software. NIST's description of patching as preventive maintenance includes applying the relevant fixes and verifying the result.6
The practical challenge comes next. Purchased products, open-source programs, and libraries publish notices and updates on different schedules. Keeping track of what affects the company, who addressed it, and what remains is not easy.
MiWork Guard compares software and components observed on servers with security information. The report answers three practical questions:17
Where is the affected software? Its location and current version.
What should change first? Target versions and work priorities.
Can it be fixed now? Fix availability and items whose actual use needs confirmation.
AI reviews collected evidence and organizes risks that deserve further attention. It supports the administrator's judgment rather than making arbitrary changes to the server.1
Turn a long list of warnings into work someone can carry out. Action plans and task lists can be saved as reports or spreadsheet-compatible files and shared with the person responsible.7
Actual action-plan screen. Internal identifying information is excluded.
A completed inspection is not a completed update. After the administrator performs remediation, another Guard inspection checks whether the change took effect and whether the previously observed issue remains.172
Connecting the initial findings, response records, and revalidation results shows what was found, how it was addressed, and what changed afterward. Trust comes not simply from keeping a record, but from checking the remediation result again.2
Tamper prevention protects those records. Remaining issues and uninspected areas stay visible, informing the next inspection or handover. This is not a guarantee of safety beyond the inspected scope.12
An excerpt from the actual activity history. Internal identifying information is excluded.
The current scope is Linux servers and running Docker containers. Administrators perform the actual updates; areas that could not be fully checked are marked partial or uninspected.17
The gap is often not a lack of security knowledge, but the amount of work to keep in view. Reducing that gap and following through with action and revalidation is why MiWork Guard is needed.
Key takeaway
On-Sitehub's AI-assisted risk assessment review reads each subcontractor's assessment items and classifies them as acceptable, requiring improvement, or inadequate. It checks whether the accident type, hazard, control measure, and risk rating fit the work context, then presents its reasoning and proposed revisions. The safety manager compares the current values with the AI suggestions and applies only the changes that are needed. The responsible person retains the final decision and completes the review.
When many subcontractor risk assessments arrive at once, safety managers often find themselves reading similar statements repeatedly.
They need to verify that the accident type matches the stated hazard, that the control measure can actually reduce the risk, and that the assigned risk rating is appropriate. Reviewing the main work category, detailed task, work location, and number of workers at the same time becomes even harder when every document uses a different format or wording.
As the number of items grows, so does the chance of overlooking something. The order in which items are reviewed may also vary depending on the reviewer's experience and habits.
AI does not approve or authorize the assessment. Its role in the first-pass review is to identify items that need attention and organize the evidence and suggestions that a safety manager should compare.
Depending on the site configuration, On-Sitehub allows subcontractor risk assessment data to be uploaded from Excel or entered directly on screen. Some templates can contain data for several subcontractors in one upload and then be separated into individual documents for each subcontractor.
This example screen is based on the structure of the product's preliminary-review document list. The site, subcontractor, document, revision, and item counts are all fictional.
On mobile, swipe horizontally to view the complete workflow.
1. Submission and AI review
2. Comparison and completion by the responsible person
For each item, the AI considers the following questions together:
Does the accident type match the stated hazard?
Is the hazard specific enough for the main work category, detailed task, work location, and number of workers?
Can the proposed control measure meaningfully reduce the risk and be carried out on site?
Is the risk rating appropriate in light of likelihood and severity?
After the review, each item receives one of three classifications:
Acceptable: Based on the submitted document, no revision is suggested for this item.
Requiring improvement: The overall direction is reasonable, but details need to be added, controls are missing, or the risk rating needs adjustment.
Inadequate: The accident type and hazard do not align, or the control measure is ineffective. The item needs to be rewritten.
These classifications do not determine whether a legal requirement has been violated or guarantee that a site control is adequate. They are supporting opinions based on the submitted content, focusing on specificity, consistency, and practical applicability.
In addition to the classification and review notes, the AI can suggest revisions such as:
A different accident type
An adjusted risk rating
A more complete control measure
The safety manager can compare the current value and the AI-proposed value side by side. Suggestions are not accepted as an all-or-nothing package. The reviewer can selectively apply only the accident type, risk rating, or control measure that needs to change. Before applying a suggestion, the reviewer can check the before-and-after values, and unsaved changes can be reverted.
When reviewing many items, the reviewer can filter items classified as requiring improvement or inadequate, then select the items and fields to update in a batch. The original text is not changed until a person selects the changes and saves them.
This fictional case is based on the product's comparison screen. The work details and AI suggestions are for explanation only and do not represent actual site data or assessment results.
The following examples illustrate how the feature approaches a review. Actual classifications and suggestions may vary according to the submitted document and the review criteria configured for each site.
Suppose the only control measure for a mobile crane operation is "restrict access within the working radius."
The AI may flag the item because it does not explain who will control access, where the boundary will be established, or how the restriction will be enforced. The safety manager then checks the equipment specifications, work location, and vehicle and pedestrian movements planned for the day before deciding which controls should actually be implemented.
If a work-at-height item lists only "wear a safety harness," the control may not be specific enough for the fall hazard.
The AI can review whether the accident type matches the hazard, whether the work location is described precisely, whether the control can be carried out, and whether the risk rating is suitable. It can then suggest areas that need improvement.
If a hot-work assessment lists only "place a fire extinguisher nearby," the control may be too narrow for the hazard.
The AI can assess whether the controls are sufficient for the stated hazard and suggest additional points that need confirmation. The safety manager makes the actual decision after checking the work area, nearby equipment, and materials in use.
When the responsible person edits an item after the AI review, the document status changes to Re-review required. Instead of analyzing the entire document again, the system can review only the changed items. When an AI suggestion is selectively applied, the applied value and its source remain in the history.
The review screen shows the number of items in each classification (Acceptable, Requiring improvement, and Inadequate) and lets the user filter by classification. It also provides an overall review summary and key observations for the full document. Results can be exported as a printable AI review report or an Excel file for sharing and recordkeeping.
For sites where the feature is enabled, the responsible person can mark a preliminary review as complete after the AI review. A separate completed version is created, and the latest completed version for each subcontractor can be viewed in the "Risk Assessment DB" section of the toolbox meeting record.
Completion is different from automatic approval by AI. The AI classifies items and proposes possible revisions, but the responsible person decides which suggestions to apply and whether the preliminary review is complete.
A written risk assessment cannot contain every condition that matters. Weather, worker experience, equipment condition, simultaneous operations, and site traffic may all exist outside the document.
Even when the AI improves the wording, it does not verify actual installations or working conditions on site. When the submitted information is incomplete or incorrect, the analysis will also be limited. The AI's first-pass review should therefore be used as a starting point for confirming:
Which submitted content supports each review note
Whether a suggested control can actually be applied to the work location and equipment
Whether an adjusted risk rating matches the site's criteria
Whether conditions outside the document require additional checks
An item classified as acceptable is not exempt from site verification. It must be checked again when the work category, equipment, location, or working conditions change. AI classification helps prioritize the review; it does not reduce its required scope.
Using AI for an initial review can reduce repetitive checking and organize possible improvements in advance. Safety managers can then focus more of their attention on site verification and the final judgments that require human knowledge of the actual work environment.
This feature does not replace the site's risk assessment procedure or the responsibilities of its participants. The responsible people must conduct, verify, and record the assessment according to the laws and assigned roles that apply to the workplace. AI review results are supporting information for that process. The handling and retention rules for subcontractor documents should also be confirmed before deployment.
The Excel template, upload method, preliminary-review completion process, and use of completed versions may differ by site configuration. The AI review perspective and three-level classification criteria can also be configured to match operational policies. Confirm the available scope and implementation schedule during deployment planning.
miwork hangul converts HWP documents to PDF on a server and lets users review the result directly in a web browser.
Opening one or two Hangul documents and saving them as PDF is familiar work. The situation changes when hundreds or thousands of documents must be converted in batches or prepared as searchable data.
Each document has to be opened and saved, and someone must investigate whenever the process stops. Extracting text for search or generating document previews presents the same challenge. miwork hangul began as an effort to turn this work into a repeatable server-side document processing capability.
Once a PDF is available, users can review the document in a browser without installing a separate application. It also becomes easier to connect the result to search previews, document archives, and other downstream workflows.
Uploaded PDFs can also be reconstructed as HWPX. Rather than perfectly restoring every element of the original editing structure, this feature focuses on creating a practical, editable document from the text and images in a PDF.
An HWP file is more than a collection of text. Fonts, character styles, paragraphs, tables, shapes, images, headers and footers, footnotes, and page layout information all contribute to the rendered result. Even with identical text, differences in available fonts or layout calculations can change line breaks and page counts.
It is also not a format that exposes a browser-standard DOM in the way HTML does. Hancom provides an HWP Automation development guide and open-source resources related to HWPX and OWPML, but desktop automation and large-scale processing on Linux servers require different runtime environments and system designs.
This is not about a shortcoming in a particular product. It is a technical challenge that comes with reproducing a long-established document format across different environments.
Over the past six months, we compared conversion results from a wide range of HWP documents and expanded the supported cases. Our internal tests now show a conversion success rate above 80%. Here, success means that conversion completes without an error and the principal text and page structure can be reviewed.
The HWP interpretation and PDF generation improvements developed through this work have also been incorporated into SoliDocs Viewer's Hangul document viewing capabilities. More demanding cases remain, including complex charts and equations, special objects, document-specific fonts, and precise page layouts. Documents that users agree to retain through the demo, together with the problem areas they mark, will be analyzed by type to improve these remaining cases.
The success rate is an observation based on our current internal test set, not a product guarantee. Results can vary depending on document structure, fonts, and object types, and the measurement will be updated as the test set grows.
miwork hangul runs in a Linux container without requiring the Hangul desktop application and can be connected through a server API. It can support batch PDF generation, web previews, and preprocessing for RAG and document AI workflows.
The miwork hangul demo lets users convert HWP and HWPX documents to PDF, review them in a browser, and download the result. Users can mark the page and type of any mismatch they find, and can also try reconstructing a PDF as an editable HWPX document.
TL;DR
MiWork Agents started as a place to talk with AI. It has now evolved into an AI collaboration workspace where people and AI can communicate, organize knowledge, and use work tools in the same environment. This post introduces the upgraded channels, direct messages, wiki, shared chatbots, knowledge bases, MCP connections, and enterprise operations.
Enterprise AI usually begins with a private chat: a user asks a question and the AI responds. It is useful, but knowledge stays inside an individual conversation unless it connects to the way a team already works.
Real work also includes discussions with colleagues, shared files, recorded decisions, and actions in business systems. MiWork Agents now brings people, AI, knowledge, and tools into one collaboration environment.
The point of this upgrade is not to add one more AI feature. It connects channels, the wiki, knowledge bases, shared chatbots, and MCP so AI can participate in the spaces where people already work. The following two case studies show how the upgraded capabilities connect in practice.
People and AI working together does not mean that AI takes over the work. It combines human experience and judgment with AI's ability to search knowledge and organize context that would otherwise be easy to miss.
Case Study 1. “Why did we decide to build it this way?”
A developer who recently joined the project asks in a channel:
“Why was this feature left out of the mobile version?”
Even the people who participated in the discussion several months earlier may not remember the exact reasoning. A new team member would have to read old conversations and many documents, while an explanation based on memory could omit an important constraint.
The team brings AI into the current conversation. AI uses earlier discussions visible from the current channel and accessible wiki, knowledge-base, and technical documents to organize the original requirements, constraints, and trade-offs. Existing team members verify that the retrieved context matches what happened, while the new member identifies conditions that may have changed.
People decide together whether to retain the original decision or redesign the feature. If the decision changes, AI helps record not only what changed, but why it changed.
Case Study 2. Field and headquarters solve an equipment problem together
A field technician posts equipment photos and symptoms to a channel from a mobile device:
“The vibration is stronger than usual, and the temperature is rising quickly.”
A technical specialist at headquarters asks the technician to check when the noise began, recently replaced parts, and current gauge readings. At the same time, AI searches accessible equipment manuals and maintenance history for similar symptoms, inspection points, and safety notes.
The field technician compares that information with the actual equipment and shares the results. The headquarters specialist reviews both the field observations and the organization's maintenance knowledge to determine a safe course of action. AI does not independently approve or perform a hazardous operation.
After the work, AI organizes the symptoms, evidence, actions, and results. Once reviewed by a person, the record can be saved to the wiki or maintenance history, while required parts and follow-up inspections can be registered through permission-aware work tools.
Teams can use topic-based channels, direct messages, and group conversations inside MiWork Agents.
Public and private channels
Colleague search and direct/group conversations
Message reactions and threads
Members and pinned messages
AI mentions and invitations inside a conversation
People do not have to leave their collaboration context to use AI. They can bring AI into an existing discussion to summarize it or help with the next task.
Useful discussions become difficult to find when they remain only in a message history. The MiWork Agents wiki turns channel discussions into documents that a team can continue editing.
Meeting notes, decisions, follow-up tasks, and references can be kept in one document. The wiki also supports document import/export and block-based editing.
Discuss in a channel ↓ Use AI to organize the discussion ↓ Publish it as a wiki document ↓ Let the team edit and reuse it
The goal is not only to generate an answer, but to leave behind knowledge the organization can use again.
Purpose-specific shared chatbots can handle repeated questions from teams or external visitors. Each chatbot has its own knowledge bases, visibility, and web-search policy.
Shared chatbots run separately from a user's personal AI environment. Personal memory and personal MCP connections are not exposed automatically; only the knowledge and capabilities explicitly assigned to the chatbot are used.
This supports internal help desks, policy search, product information, and customer-facing FAQ experiences.
MiWork Agents supports MCP so AI can connect to real business tools instead of stopping at a text response.
Administrators register organization-wide MCP connections, while users authenticate with their own accounts when required. AI can then query information or perform allowed work through those tools.
The important part is not the number of integrations, but controlling who can use which tool and under what authority.
An AI collaboration platform needs more than a chat interface. MiWork Agents includes an operations console for managing organizational use.
User accounts and platform roles
Teams and team membership roles
Individual, team, and organization budgets
Chat and embedding models with fallback order
Shared chatbot creation, approval, and operations
Policies and access scope
MCP connection status
Audit logs for authentication, permissions, and content changes
Administrators can monitor cost and usage, configure models and budget policies, and review important changes through audit records.
8. The same collaboration flow on desktop and mobile
The primary collaboration surfaces are also designed for mobile use. Channels, conversations, AI, and the wiki remain accessible through bottom navigation, while conversation lists and composer areas fit smaller screens without horizontal scrolling.
The aim is to keep the same work context when reviewing a document in the field or continuing a conversation while moving.
The expanded product can be summarized as one collaboration flow.
People discuss work in a channel ↓ AI joins the conversation and organizes it ↓ Knowledge bases provide grounded sources ↓ Decisions and follow-up work move into the wiki ↓ Connected tools carry out permitted actions through MCP ↓ Administrators manage access, budgets, models, and audit records
With this upgrade, MiWork Agents has become an AI collaboration workspace where people and AI work together.
It is not intended to replace human collaboration with an AI conversation. It brings AI into the environment where people already communicate, find knowledge, create documents, and use work tools.
TL;DR
Minisoft's official MiWork site, miwork.ai, is now open. It brings together MiWork OCR for turning documents into usable data, MiWork Agents for connecting organizational knowledge to work, and MiWork VibeHub for building and operating internal apps.
When a company starts applying AI to work, the questions usually fall into three groups:
How do we read and use scattered PDF, HWP, and Office documents?
How do we connect organizational knowledge and work tools to AI answers and actions?
How do we build, review, deploy, and operate the small apps that teams actually need?
MiWork brings these questions into one work-solution family instead of leaving them as a disconnected product list. Each solution can be explored and adopted independently, with a clear place to start for a specific problem.
MiWork OCR converts PDFs and images as well as HWP/HWPX, Word, PowerPoint, Excel, and HTML into structured, page-level results.
Short jobs can return immediately, while longer documents can be submitted and tracked until the result is ready. The product page also describes table handling and configurable OCR engines for different document types and accuracy/speed requirements.
Before a document can become searchable knowledge or feed a downstream AI workflow, it has to be read and structured reliably. MiWork OCR covers that first step.
MiWork Agents is an enterprise AI agent workspace that connects organizational knowledge and work tools.
It brings document search and RAG, team knowledge bases, personal file workspaces, shared chatbots, and tool connections into one environment. Answers can include their source documents and continue into file work or connected business actions when needed.
For enterprise AI, operating standards matter as much as model quality. MiWork Agents also considers user and team access control, separated execution environments, credential management, usage and budget visibility, and audit records.
MiWork VibeHub connects the full lifecycle of internal apps: create, review, deploy, discover, and operate.
App users can find and run the tools they need from an app store and personal dashboard. Builders can start from templates or their own Git repositories and use AI coding tools and shared platform services. Reviewers and operators manage visibility, app membership, deployment and rollback, runtime status, and logs.
When a field idea becomes a cost calculator, bid analyzer, or inspection tool quickly, speed is only part of the problem. Teams also need to decide who can use it, what data it can see, and how it is deployed and rolled back. VibeHub provides that operating foundation.
Each product can stand alone, but the shared flow becomes clearer when they are used together.
Document upload ↓ MiWork OCR — structured data ↓ MiWork Agents — knowledge search, questions, and actions ↓ MiWork VibeHub — build, deploy, and operate the work app
Organizations do not have to adopt them in this order. Some will start with document processing; others will start with team knowledge search or internal app operations. The site describes the current scope of each solution and provides a path to request an introduction.
This opening is not a claim that the product story is finished. It is a starting point for explaining the work solutions we are building in one place. We will keep updating the site as the product scope and use cases become more concrete.
MiWork is not meant to be another screen with an AI feature attached. The goal is a connected flow in which documents become knowledge, knowledge becomes action, and the tools teams need can be safely operated inside the organization.
Take a look at the current direction and product family on the official site. Starting with one recurring work problem is enough.
There was no single name for all of it. Presenting our products meant reading a list. "There is an AI Agent platform, and there is a mini app platform…" A list tells people what each product is. It does not tell them what this company does with AI.
The names did not explain the products. LUMINUS came from the Latin for light. It was pleasant to say, but nobody could tell what the product did from the name alone, so every introduction opened with an extra line of explanation. MiWork already has Work in it.
"Mini app" got too narrow. Today someone in the field describes what they need to an AI and a cost calculator or a bid analyzer appears in a short sitting — the flow usually called vibe coding. Apps made this way are not mini because they are small; what changed is the speed and the method of making them. VibeHub puts that change into the name.
Two products carry the MiWork name today: Agents and VibeHub. As more AI-based work products arrive they may join the same system, but which ones and when is not decided yet.
Renaming a product does not make it better. Helping people find you when they search, and telling them several products belong to one family without anyone having to explain it — that is about all a name does.
MiniApp Hub is now MiWork VibeHub. This post has been updated to use the new name.
TL;DR
A work platform in the AI era needs to manage not only ERP or groupware, but also spreadsheets, macros, Python tools, AI Agents, and vibe-coded apps. MiWork VibeHub aims to make scattered work tools searchable, shareable, installable, and operable as company assets.
Connecting scattered work assets, from Excel files to vibe-coded apps
Companies have long adopted systems such as ERP, groupware, MES, and CRM to digitize work. These systems still support many core business processes.
But generative AI and coding agents are changing how work tools are created. Small internal tools can now be built faster, by more people, and in greater numbers. The question is no longer just whether a company can build apps. The question is how those apps can become lasting company assets.
In the past, creating a business system required a long project. Teams had to define requirements, secure budgets, build, test, and deploy.
Now, generative AI and coding agents allow business users to create small tools for their own work.
Meeting note assistants, purchase request apps, quotation generators, bid analysis tools, cost calculators, and contract review tools can be created much faster than before.
AI is lowering the cost of building software. In the near future, one employee may create several work apps, and each department may continuously produce new tools.
In the past, companies lacked systems. In the future, they may have too many tools to manage.
An enterprise mini app platform such as MiWork VibeHub is one way to support this flow.
Spreadsheet-based tools, scripts, AI agents, and vibe-coded web apps can be registered as business assets.
Users can search for and install the tools they need. The company can manage who uses which app, what version is running, and which tools are gaining traction.
Future Competitiveness Will Come from Accumulated Work Assets
AI will create more business tools. The important question is not how many apps a company can create.
It is how well those apps can be shared, operated, improved, and preserved as organizational assets.
Future competitiveness may come not from the number of systems a company has, but from how well it accumulates and operates work assets.
MiniApp Hub Enterprise is now MiWork VibeHub. Screenshots and the guide video in this post still show the former name.
TL;DR
MiWork VibeHub turns work apps that used to stay with one person or department into company-managed assets. App store, installation status, usage data, permissions, and version management help small work ideas spread across the organization.
An enterprise mini app platform where anyone can build, everyone can use, and the company can govern.
Companies already have many internal tools: inspection apps, report automation tools, data dashboards, chatbots, and request forms created by different teams. The problem is that even useful apps are often hard to find and hard to scale across the company.
In many organizations, business apps are created and managed separately by each department. Links, files, and tools are scattered, and useful apps are often not discovered. Similar apps are rebuilt, maintenance costs increase, and security or permission rules become unclear.
MiWork VibeHub is an enterprise mini app platform that lets employees find internal apps like an app store, install them, and run them from a personal dashboard.
MiWork VibeHub solves this with an internal app store model. Employees search for the apps they need, install them, and the installed apps are automatically added to their personal dashboard. Ratings, comments, and rankings help useful apps spread naturally.
Companies have more internal work tools than they often realize. A spreadsheet refined by a business user, a small automation script created to reduce repetitive work, or a team-specific dashboard can already be a useful operational asset.
MiWork VibeHub gives these tools an official channel so they do not remain on personal devices or inside a single department. The point is to help useful apps be discovered, governed, and reused across the organization.
Useful business apps can be shared across the organization.
Apps created by individuals can be managed as company assets.
Installation status and usage status can be checked.
Versions and permissions can be governed systematically.
Field ideas can accumulate as digital assets instead of remaining personal convenience tools.
The internal app store is an official catalog of verified mini apps. Users can search by categories such as safety, quality, purchasing, HR, administration, and report automation. They can compare apps by ratings and installation counts.
Installed apps are automatically added to the personal dashboard. Frequently used apps can be pinned, and work alerts such as approval requests, unfinished tasks, and report status can be checked in one place.
Convenience is not enough for an enterprise platform. MiWork VibeHub also covers company-account SSO, role-based access control, install/run/access logs, and an app approval process.
By separating the roles of users, app creators, app owners, approvers, operators, and review managers, the platform balances business autonomy with company-level control.
MiWork VibeHub brings business apps that were previously scattered across personal PCs or individual departments into an official channel. By publishing only approved apps and operating them based on usage data, the company can reduce shadow IT, encourage app sharing, and manage field ideas as digital assets.
Employees can run frequently used apps from one screen and reduce repetitive work. Business teams can turn ideas into apps faster and spread best practices across the company. IT and DX teams can manage the app portfolio based on usage data, and executives can see which innovation cases are actually being used.
The goal of MiWork VibeHub is not simply to create more apps. It is to make internal mini apps easier to find, safer to install, and easier to scale based on real usage data.
For small ideas from the field to become company assets, organizations need not only tools for building apps but also a platform for collecting and operating them.
TL;DR
InfraManager and MiNa aim to connect servers, DNS, certificates, containers, and ownership into one impact map when an infrastructure alarm occurs. Operators need a fast answer about what is affected, not another list of menus.
A phone rings in the middle of the night. "api.example.com is not responding." Half-awake, the operator usually thinks through the same questions. What is affected, who owns it, has this happened before, and is it safe to touch now?
It is similar to the triage that a medical team performs when a patient enters the emergency room. From one symptom, they quickly connect impact, priority, and ownership. This article focuses on what operators look at when cloud infrastructure starts to shake.
Traditional operation screens are usually divided by menu. Server lists, DNS lists, container lists, and certificate lists are viewed separately. Each screen may be organized well, but what operators really need is the relationship between them.
If a domain goes down, which services are affected next? Who owns it? How was this handled in the past? The answers are scattered across menus, and operators have had to connect them in their heads.
In emergency-room terms, the charts are all there, but no one is doing triage. The doctor has to open each chart and build the picture mentally.
InfraManager is an operations dashboard we are building to connect scattered information into one operation chain.
Domain -> DNS -> proxy -> container -> server -> backup -> owning team -> runbook.
When an operator selects api.example.com, the system follows this chain and unfolds everything connected to it on one screen. Instead of asking, "Where was that again?", the operator can start with, "What should we do?"
Costs are viewed in the same way. If this month's bill increased, InfraManager shows which subscription increased, which resources are tied to that subscription, and who created those resources. Following one number reveals the people and systems standing behind it.
AI infrastructure teammate MiNa works on top of InfraManager. Operators ask in natural language, and MiNa chooses the needed tools, combines the results, and answers.
The actual questions operators ask often look like this.
"What is affected if this domain goes down?" - MiNa brings DNS, proxy, service, server, and owning team together.
"Why did this month's cost increase?" - MiNa connects subscriptions, resources, change history, and cleanup candidates.
"Are there servers without working backups?" - MiNa combines backup policies, failure history, and recovery targets.
"Has a similar incident happened before?" - MiNa retrieves past events, actions taken, and whether the issue recurred.
Just as emergency triage uses one symptom to decide the next care flow, MiNa uses one question to gather the screens, materials, and people the operator should look at next. Instead of visiting five menus, the operator asks MiNa first, and the system checks the real data.
The hardest part of infrastructure operations is not only checking whether a server is alive. During an incident, operators must quickly connect impact, ownership, past cases, and whether it is safe to act now, then decide the next action.
Until now, this has depended on people memorizing the infrastructure in their heads. As infrastructure grows and owners change, that approach becomes fragile. When the system remembers relationships and AI turns those relationships into answers for operators, operational pressure moves away from human memory.
We are using InfraManager and MiNa directly for internal infrastructure operations, building a flow where operators can ask the system first instead of relying only on their memory when a late-night alert arrives.
In the next article, we will look inside how MiNa selects tools and combines answers.
TL;DR
MiNa first needs to distinguish whether the user only wants to inspect something or actually change infrastructure. Separating read-only work from change actions is what makes AI operations fast and safe.
In the previous article, we explained how MiNa answers an operator's question by combining impact, ownership, and past cases. For a question like "What is affected if this domain goes down?", MiNa gathers DNS, proxy, service, server, and owning team together.
But operators do not always ask read-only questions. Some questions change things: "Delete this container," "Stop this GPU job," or "Lock this user account." If the same MiNa answers those questions in the same way, it becomes dangerous.
This article is about the one question MiNa asks: "Are you only looking, or are you going to change something?"
Emergency teams do two different kinds of work. They read patient charts, and they also prescribe medicine or decide on procedures. The same doctor may do both, but the process is completely different. Opening a chart does not change the patient. A prescription can affect the patient immediately if it is wrong.
When MiNa receives an operator's question, it first makes the same split. "Is this a read-only question, or is it a change request?" The same MiNa asks and answers, but the two paths are different.
For these questions, MiNa does not need deep deliberation. It directly calls the required tool and returns the result. In emergency-room terms, it immediately opens the chart. Fast answers help operators make the next decision quickly.
Change requests cannot move at the same speed. MiNa goes through three steps.
1. Answer the impact first with a dry run
MiNa first shows, "If this is removed, these things will be affected." Even for deleting one container, it shows the site supported by that container, the connected proxy, and log-retention policy. Nothing has actually been changed yet.
2. Check the owning team
MiNa also answers who owns the area: "This belongs to the infrastructure team," or "This requires the data team's authority." This protects operators from casually making changes outside their responsibility.
3. Wait for explicit approval
MiNa does not execute until the operator explicitly confirms. It is similar to getting consent before a risky procedure in the emergency room.
If there is only a fast path, operations become dangerous. A change request could be executed before the operator understands its impact.
If there is only a careful path, operations become frustrating. If even simple read-only questions ask for confirmation every time, operators will stop asking MiNa and go back to clicking through menus manually.
Fast triage plus careful treatment - the same shape that helps an emergency room work well also applies to infrastructure operations. Both tracks need to exist together.
MiNa's ability to combine answers is important, but so is its ability to know when to stop and ask the operator again. The MiNa we use every day with internal infrastructure answers quickly when speed matters, and pauses when care matters.
In the next article, we will look at the operation chain MiNa follows: how it starts from one domain and traces all the way to backups and owning teams.
TL;DR
Smart On-sitehub turns daily work reports into shared data for process management, risk assessment, safety management, and electronic documents. It connects work, location, people, and risk factors so construction site information does not stay scattered.
A construction site generates a large amount of information every day.
Managers need to know who is working, where the work is happening, what tasks are in progress, which risks exist, and where the related documents are stored. In many real-world sites, however, this information is scattered across daily reports, Excel files, messengers, and paper documents.
Smart On-sitehub by Minisoft is a smart construction site platform designed to solve this problem. It connects safety management, process management, risk assessment, and electronic document management into one workflow so that site managers can understand the entire field at a glance.
The key idea is digitizing daily work reports.
When a worker or partner company submits a daily work report, the system connects who is working (OBS), where the work is performed (PBS), what task is being done (WBS), and which safety risks are involved (SBS). The report is no longer just a record. It becomes the base data for process tracking, risk assessment, and daily site monitoring.
In Smart On-sitehub, daily work reports are transformed into Activity Data. This data is used across risk assessment, safety management, process management, and electronic document management.
Information from each area is collected into an integrated dashboard, allowing managers to monitor the site in real time.
One of the most important features is automatic risk assessment linkage.
In many construction sites, risk assessments are managed as separate monthly documents and are often disconnected from actual daily work. Smart On-sitehub links risk assessment directly to the daily report, including work details, location, and workforce information, making safety management more practical and work-based.
Safety training confirmations, consent forms, inspection logs, and work plans can be managed as electronic documents. The platform also supports electronic signatures, QR-based workflows, and multilingual training content for foreign workers.
Documents generated on site are not just files to be stored. They become operational data. Teams can search, share, approve, and track documents more efficiently.
TL;DR
OCR turns text inside scanned or image-heavy documents into searchable text, while Graph RAG uses relationships between documents and entities. This helps with reports, contracts, and incident records where simple keyword search misses the context.
In the previous article, we compared RAG to a librarian. The librarian finds materials related to the user's question and hands them to the LLM. But what happens if the book that arrives at the library has no text at all, only images and tables? What if the materials are part of a complex event where many documents are connected to each other?
This article looks at the next two walls RAG runs into, and how OCR and Graph RAG help cross them.
OCR extracts text and table structure from documents, while Graph RAG connects the relationships between extracted entities. Vector search and answer generation sit on top of that flow.
The RAG we discussed earlier splits documents into small chunks, converts them into meaning-based numbers called vectors, and stores them. When a user asks a question, it finds chunks with similar meaning and sends them to the LLM.
The problem appears in two situations.
1. When the text is inside an image
Scanned PDFs, photographed contracts, quarterly reports full of tables. If text cannot be extracted, there are no chunks to split. It is like the librarian saying, "This book is only photos, so I cannot read it."
2. When materials are connected to each other
Consider a question like, "A similar process is happening at the site where an incident occurred last year. Which safety rules apply?" Incident records, process standards, and regulations are separate sources. If they stay separate, the answer does not come together. The librarian can find one book at a time, but may not connect the relationships between them.
OCR - A Librarian That Can Read Text Inside Images
OCR solves the first wall. OCR stands for optical character recognition. It extracts text from images.
Modern OCR is not only about reading letters. The important part is recognizing table structure, paragraph position, and the hierarchy between headings and body text. This makes a large difference in fields that contain many dense tables, such as credit review documents, construction specifications, and medical imaging reports.
Once OCR extracts the text, the rest flows into the ordinary RAG process: split by meaning, convert into vectors, store, and search when a question arrives.
Graph RAG - A Librarian That Sees Relationships Between Materials
The second wall is Graph RAG. As the name suggests, it combines a graph database with RAG.
If ordinary RAG finds "chunks with similar meaning," Graph RAG also stores relationships between materials.
For example, suppose there is an incident called "2024 utility tunnel work incident." That incident may be connected to the following items.
When those relationships are tied together as a graph, a single question such as "What should we check for today's utility tunnel work at height?" can bring all four materials together. The LLM can then answer at once: which regulation applies, which checks are needed, and which similar incident should be considered.
The value of Graph RAG is that users no longer have to find materials separately and connect them in their heads. The system already knows the relationships and brings related materials together.
OCR and Graph RAG shine in fields where materials are image- or table-heavy, and the materials are strongly connected to each other.
Finance - credit review and market analysis
Business plans, financial statements, and market reports can span dozens of pages. OCR brings tables and charts into text, and Graph RAG connects companies, industries, and regulations, so a person in charge can receive the key points from one question.
Industrial safety - field guidance
Government safety guidelines, internal specifications, and past incident collections are often used together. When a field manager asks what to check for today's utility tunnel work at height, the system can immediately combine regulations, rules, and similar cases.
RAG is not a technology that becomes complete all at once. It moves step by step from finding text, to reading information inside images, to connecting relationships between materials.
Minisoft operates this staged RAG approach in finance and industrial safety domains, and we keep experimenting every day with ways to make the librarian smarter.
TL;DR
RAG retrieves materials related to the question first, then lets the LLM answer from that evidence. This matters for enterprise chatbots that must reflect current internal documents and policies.
Have you ever asked, "What is our vacation policy?" and seen a chatbot answer with the correct internal rule? A public LLM does not know your company's private documents, so how is that possible? The key is RAG, retrieval-augmented generation. Let us explain it with a librarian analogy.
Imagine a friend who is an expert in a field but knows nothing about your company. Asking that friend "What is our vacation policy?" is like asking an LLM directly.
Now take that friend to a library. The librarian finds the company policy book and hands it over. "The answer should be in this book." Your friend reads it and answers, "Vacation starts after one year of employment, with 15 days, and requests are submitted this way."
That is the core idea of RAG.
A user asks a question -> the librarian finds related materials
Those materials -> are handed to the expert, the LLM
The LLM answers from the materials -> the answer becomes grounded
For a librarian to find things quickly, the shelves need to be organized. RAG is the same.
All company documents, manuals, policies, FAQs, and emails are split into small chunks. Each chunk is converted into a bundle of numbers called a vector. That vector represents the meaning of the sentence.
Sentences with similar meaning become similar numbers. "How to request vacation" and "How to use annual leave" use different words but have close meaning, so their vectors are close.
Step 2: Find Similar Materials When a Question Arrives
When a user asks, "How do I use vacation?", the question is also converted into a vector. The system then searches stored document vectors for the closest meanings.
This type of database is called a vector database. It works like a library catalog. A paragraph about the vacation request process is retrieved.
Step 3: Give the LLM the Question and the Materials
Now the LLM receives a request like this:
"Answer the user's question using the following source.
[Source] Internal vacation requests are submitted through HR -> Vacation Request...
[Question] How do I use vacation?"
The LLM reads the source and answers in a way the user can understand.
"Log in to the groupware system, then go to HR -> Vacation Request. First choose the vacation type..."
If the source does not contain an answer, the system can be configured to say, "This information is not in the provided materials."
New employees can ask a chatbot instead of searching the internal wiki. Everyday questions such as "How do I settle travel expenses?", "My VPN is not connecting", or "How do I reserve a meeting room?" can be answered immediately.
When customers ask product questions, RAG searches manuals, FAQs, and past support records to answer. It works 24 hours a day and passes complex issues to human agents.
These fields depend on finding accurate information from large sets of regulations, cases, papers, or policies. RAG can greatly reduce the time spent searching and summarizing.
Too little context makes the answer incomplete. Too much context makes the LLM miss the point. Usually three to five paragraphs is a good starting point.
RAG is not magic. It automates something people already do: search for the right material, read it, and answer from it. Minisoft is using RAG in internal knowledge systems and customer support chatbots while learning every day how AI can fit into real work.
TL;DR
A multimodal LLM can be useful as an assistant that quickly summarizes possible risk factors from site photos. Final safety judgment still needs verifiable criteria and human confirmation.
Testing safety inspection support with site photos and safety-rule prompts
Field safety inspections still depend heavily on human experience and manual work. Inspectors need to review site photos, check protective equipment and risk factors, and then write the findings into a report.
Recent multimodal LLMs can understand images and text together. This PoC explored whether site photos and safety-rule prompts can be used to support safety checks and draft inspection reports.
The goal was not to make final judgments about a specific site or device. The goal was to check whether a multimodal LLM can act as an assistant for industrial safety inspection.
Validate whether safety rules can be checked from site photos
Check whether rules can be applied through prompts without separate model training
Explore risk summarization and inspection report drafting
Consider future expansion into video-based inspection flows
The input flow was intentionally simple. A site photo was provided with a prompt containing safety rules and the desired output format. The model was asked to identify visible workers, protective equipment, and risk factors, then return a structured inspection result.
The advantage of this approach is that teams can experiment without first preparing a dedicated training dataset or a specialized vision model. By changing the prompt, the inspection criteria and output format can be adjusted quickly.
The approximate number of workers in the photo could be estimated.
Visible risk factors could be summarized.
Inspection results could be organized into a report format.
There were also clear limits. Accuracy dropped with low-resolution images, distant workers could be missed, and small or partially hidden details such as safety harness fastening were difficult to judge reliably.
In this test, the multimodal LLM was more suitable as an inspection assistant than as a final decision maker. It was useful for summarizing visible risk candidates and organizing the items that a human inspector should review.
Report drafting was especially promising. Instead of writing every finding from scratch after reviewing photos, inspectors can start from a generated draft and focus on final confirmation and correction.
The next step is to explore a flow that extracts snapshots from CCTV, drone, or mobile video and uses them for periodic safety inspection support.
The point is not to let AI replace all safety judgment. Field safety requires responsibility and context. A realistic starting point is to use AI to support repetitive inspection, summarize risk candidates, and help people focus on more important decisions.
Multimodal LLMs show potential for interpreting site photos together with safety rules. They are not reliable enough to judge every situation on their own, but they are worth testing for safety inspection assistance and report automation.
In industrial safety, AI can start by helping people see faster and record more consistently, rather than replacing human responsibility.
LUMINUS is now MiWork Agents. This post has been updated to use the new name.
TL;DR
The AI Agent era is about multiple agents handling documents, images, data, and workflows together. MiWork Agents is evolving toward a platform that creates, connects, and manages those agents.
AI is no longer limited to a single chatbot.
AI that understands documents, AI that analyzes images, AI that works with data, and multiple AI Agents collaborating with one another are quickly becoming part of enterprise work.
This shift raises new questions for companies.
How should AI Agents be created, connected to business data, and managed safely?
MiWork Agents is evolving as a platform for creating, connecting, and managing AI Agents in response to this change.
The key to the AI Agent era is not simply using more tools. It is building an operating model that reliably connects enterprise work assets with AI.
LUMINUS is now MiWork Agents. The original article refers to the product by its former name, LUMINUS.
TL;DR
An enterprise AI Agent platform is more than a chat screen. It needs to connect documents, data, and business systems while keeping permissions, security, and operating policies under control.
MiWork Agents was recently introduced as an enterprise-focused AI Agent platform.
We believe the important question is not only how to use AI, but how to connect AI Agents and operate them safely.
In enterprise environments, AI Agents need to go beyond conversation. They need to connect with documents, data, and business systems while staying within clear permission, security, and operating policies.
MiWork Agents started from this concern.
We will continue developing MiWork Agents as an AI platform optimized for enterprise environments.
TL;DR
Fashion image search lets users find similar products from one photo even when they do not know the product name. The core idea is to convert product images into embedding vectors and compare them with the uploaded image.
Users do not always know the exact product name they want to search for. They may have a photo of a pair of shoes, an outerwear item from an outfit image, or a bag with a similar shape, but not the right keyword.
This PoC was built for that situation. A user uploads one image, the system extracts visual features, compares them with product image vectors in the catalog, and recommends similar products.
Text search works well when product names, brands, categories, and colors are cleanly managed. Fashion products are different. The same product can be described in many ways: "white sneakers", "chunky sole shoes", or "daily casual shoes".
Image search reduces that gap. By comparing shape, color, silhouette, and pattern from the user's image, the system can find similar products even when the text query is incomplete.
Users can upload an image or search by product name. Category filters help narrow the result set.
Search results are shown with similarity scores. Operators can review whether the recommendations are close to the intended product group and adjust image quality, category data, and embedding status.
Real users are more likely to have outfit photos or field photos than clean front-facing product images. The test screen was designed to check whether the system can find similar products from an uploaded image.
Improving the result quality is not just about changing the model. Backgrounds, angles, resolution, and category quality also matter. In a PoC, these quality factors need to be visible early.
In an image search service, the management screen is as important as the search screen. If product images change but embeddings are not refreshed, search results will still be based on old data.
The product management screen needs to show image count, embedding status, and review status together. After a product is added or images are updated, embeddings should be regenerated so the search result reflects the latest data.
The goal of this PoC was not to build a complete commerce service. It was to check whether image search could support product discovery in a practical workflow.
The validation points were straightforward: whether similar products appear quickly after image upload, whether category filters improve result quality, whether operators can understand image and embedding status, and whether new products can be reflected in search after registration.
Image search does not simply replace text search. It complements the moment when users cannot describe what they want in words.
For visually driven domains such as fashion, product images, catalog data, vector search, and management workflows need to work together. To become a real service, the system must support not only the result screen but also the operational flow for maintaining and refreshing images.
LUMINUS is now MiWork Agents. The original article refers to the product by its former name, LUMINUS.
TL;DR
MiWork Agents was introduced as an enterprise AI Agent Platform. This short note summarizes the direction covered in the article and why companies need a safe way to connect AI Agents with real work systems.
MiWork Agents is an Enterprise AI Agent Platform designed to help companies create AI Agents, connect them with enterprise data, and operate them safely.
Over the past two years, we have been thinking about how AI can be applied to real work and how enterprises should manage AI Agents.
The article introduces key MiWork Agents capabilities, how it can be used in enterprise environments, and its vision as an AI Agent Platform.
MiWork Agents will continue to evolve with changing technology trends.
TL;DR
Introducing LLMs is not just choosing a model. To make AI useful in daily work, teams need retrieval, permissions, review steps, and security practices designed as one operating system.
You have probably heard the phrase, "AI will take people's jobs." But inside a company, it is often hard to see how AI is actually used. Here is the practical story of what Minisoft experienced while bringing LLMs, or large language models, into our work over the past year.
A work request does not end with the LLM alone. Internal data retrieval, human review, and final output validation are what make the result usable in real business.
Traditional chatbots answered fixed questions with fixed responses. If a user asked in a slightly different way, the answer was often, "Sorry, I did not understand."
LLMs are different. They understand sentences as people write them, read the context, and generate an answer. It feels a little like giving a new employee the entire manual and letting them answer freely.
Sometimes it invented internal policies that did not exist. This is the familiar problem of hallucination. If an employee trusts the wrong answer, the damage can be real.
The answer was RAG, or retrieval-augmented generation. The system searches internal documents first, then passes those materials to the LLM with a prompt such as, "Please answer using these sources."
Think of a librarian. When you ask about a topic, the librarian first finds the relevant books, then helps answer from those books. If the answer is not in the book, the system can say so honestly.
New employees started asking the bot instead of searching the internal wiki. Questions like "How do I settle travel expenses?" or "My VPN is not connecting" became easier to resolve. Repeated HR and admin questions dropped by about 40%.
Upload a two-hour meeting recording, and within five minutes the system produces a summary, action items, and owners. The 30 minutes usually spent cleaning up notes after meetings disappeared.
On the engineering team, an LLM now performs the first pass when a pull request is opened. It catches obvious mistakes, security risks, and convention violations. Human reviewers can spend more time on the design decisions that matter.
1. AI is a tool, not magic
The key is deciding what to delegate to AI and what must stay with people.
2. Data cleanup is half the work
For an LLM to answer well, internal documents must be organized. We had to clean up documents before the AI work could succeed.
3. Start small, then expand
We did not try to automate everything at once. We solved one problem for one team first, then expanded after the effect was proven.
LLMs are not magic. But used well, they reduce repetitive work and let people focus on more important decisions. In the next article, we will look more closely at how a RAG system is built.
TL;DR
The key to IoT in the field is not just installing sensors. Value appears when sensor data becomes dashboards, alerts, and decisions that operators can use every day.
Smart factories and smart logistics show up often in the news, but it is not always clear what actually changes inside a factory. Here is a plain look at how IoT changes real work, based on field projects Minisoft has built.
In the old way, operators walked around each machine asking, in effect, "How are you feeling today?" Now they check a dashboard on their phone on the way in. Vibration, temperature, and current data from every machine has already been collected overnight.
Only Line 3, where an abnormal signal appeared, needs attention. Inspection time dropped from one hour to ten minutes.
The motor on Line 3 shows vibration that differs from its normal pattern. The system sends an automatic alert.
"Line 3 motor bearing anomaly detected. Inspection recommended within 72 hours."
This is predictive maintenance. Instead of fixing equipment after it breaks, the team catches risk before failure. When a stopped line can cost millions of won per hour, one early maintenance action can prevent a large loss.
Each parts box has a weight sensor. When a box drops below a certain weight, the warehouse system creates a replenishment request automatically. Operators no longer discover missing parts only after they run out.
In large warehouses, people spend more time than expected looking for items. With RFID and beacons, every box's current location appears on a map. Tap "find" on a handheld device, and the route appears.
Environmental Monitoring - The Lifeline for Food and Medicine
In a pharmaceutical warehouse that depends on cold-chain storage, even a one-degree temperature deviation can make products unusable. Temperature sensors measure every minute and alert the person in charge the moment a threshold is exceeded. The risk of a silent incident drops dramatically.
When forklifts have collision-detection sensors, they can slow down or stop automatically when they come too close to a person. Accidents fall, and so does the psychological pressure on workers.
IoT adoption does not have to begin with a grand project. One small manufacturer Minisoft worked with started with five vibration sensors on a single line. Within six months, line uptime increased by 12%, and the company expanded gradually to all lines.
The key is to first ask, "Where is cost leaking?" It is not about attaching sensors everywhere. It is about placing them where they matter.
IoT is not science fiction. A small sensor, a system that gathers its data, and people who interpret the signal can change the field in very practical ways. Minisoft will keep listening to field problems first and building answers with data.
