Situ — Enterprise Architecture Studio

An old friend asked if I could build an AI sidekick for ITSM.

Not a replacement for the service desk. Not an autonomous agent that closes tickets because a model sounded confident. Just a practical assistant that could sit beside the work: read a ticket, understand the shape of the problem, surface useful context, suggest next steps, and keep the human in control.

That was the prompt.

This morning I hacked together the rough framework with a local model. Just now, after dropping my son off at prom, I polished it up a bit more. Somewhere between "this is probably a weekend experiment" and "this is useful enough to keep going," the obvious question appeared:

Why not just open-source it?

So I did.

You can try the demo and read the source here:

Live demo: tickety.situ.io

GitHub: github.com/bellchu/tickety

Because a repo is more useful when people can actually see the thing, I wanted both links to be front and centre: the running demo for a quick feel, and the source for anyone who wants to see how it is put together or adapt it for their own ITSM workflow.

Why ITSM needs a sidekick

Most ITSM work is not glamorous. It is intake, triage, classification, summarisation, routing, duplicate detection, status updates, knowledge base lookups, and the hundred tiny decisions that happen before anyone touches the actual fix.

That work matters. Bad intake wastes engineering time. Bad categorisation hides systemic problems. Bad summaries make every escalation slower. Bad ticket hygiene turns the service desk into a swamp.

It is also exactly the kind of work where AI can help without pretending to be the operator.

The useful version of AI in ITSM is not "let the model run production." The useful version is:

Summarise the ticket. Strip out the noise, preserve the signal, and make the actual request obvious.

Ask better follow-up questions. If the ticket is missing hostname, user impact, error text, timestamps, screenshots, recent changes, or affected service, say so.

Suggest a category and priority. Not as a final decision, but as a starting point for the person working the queue.

Find related history. Similar incidents, repeated symptoms, matching assets, known fixes, stale runbooks.

Draft a human response. A clear update the technician can edit, not a fake-sincere paragraph sprayed into the ticket.

None of that requires magic. It requires context, guardrails, and a workflow that respects the fact that ITSM data is messy.

Why local first

The first Tickety prototype runs against a local model.

That was intentional. ITSM data is full of sensitive details: names, emails, asset identifiers, internal system names, incident timelines, sometimes customer data. Shipping all of that to a hosted model by default is a non-starter in many environments.

Local models are not perfect. They are slower, smaller, and more uneven than the big hosted models. But for a lot of service-desk assistance, perfect is not the bar. Useful is the bar.

If a local model can produce a good ticket summary, identify missing fields, suggest a category, and draft a sane response, that is already valuable. The human can still review it. The ticket system can still enforce approvals. The organisation can still decide where hosted models are allowed later.

Start conservative. Earn trust. Expand from there.

What I built today

The first version is a framework, not a finished product.

It has enough structure to take a ticket-shaped input, pass it through an AI-assisted workflow, and return output that is meant for a technician to review. The important part is not the specific prompt. Prompts change. Models change. Ticket systems change.

The important part is the shape:

Keep the human in the loop. Tickety should assist decisions, not silently make them.

Make reasoning visible. If it suggests a category, priority, or next step, it should explain why.

Treat missing information as a first-class output. Sometimes the best answer is "you cannot triage this yet."

Use local context carefully. Runbooks, known issues, service names, escalation paths, and past incidents are where this gets useful.

Avoid pretending certainty. ITSM has too many edge cases for confident nonsense.

That is the line I want Tickety to walk: helpful enough to save time, cautious enough to be trusted.

The prom-drop-off polish pass

There is something funny about the timing.

I wrote the rough framework in the morning, then went back to normal life. Later, I dropped my son off at prom. Big milestone. Real life. One of those moments where time folds a little and you realise the kid who used to need help tying shoes is now walking into a night he'll probably remember forever.

Then I came home and cleaned up an ITSM AI side project.

That is how a lot of useful software happens, at least for me. Not in a grand launch moment. In the cracks between obligations. A friend asks a practical question. A rough idea becomes a script. The script becomes a small framework. The framework starts to look like something other people might use.

And then you either let it sit in a private folder, or you put it out there.

Why open source

ITSM tooling is full of locked boxes. Some of that is reasonable. Enterprises need support, compliance, audit trails, integrations, and someone to call when things break.

But the AI layer should be inspectable.

If a tool is going to help summarise incidents, suggest priorities, draft responses, or reason over operational data, teams should be able to see how it works. They should be able to change the prompts. Swap the model. Remove a workflow. Add their own guardrails. Run it inside their own boundary.

Open source is also the fastest way to find out whether the idea is useful outside my own head.

Maybe Tickety becomes a small toolkit. Maybe it becomes a proper app. Maybe someone plugs it into Jira Service Management, ServiceNow, Freshservice, or a homegrown ticket queue. Maybe someone takes one piece of it and builds something better.

That is fine. That is the point.

What comes next

The next useful work is obvious:

Connectors. Ticket systems, knowledge bases, asset inventories, monitoring tools.

Evaluation. Real ticket samples, expected outputs, regression tests, and a way to measure whether changes make the assistant better or just more verbose.

Policy controls. What can be sent to which model, what must stay local, what fields need redaction, what actions require approval.

Better retrieval. The sidekick gets much more useful when it can pull the right runbook, incident, or service note at the right time.

Cleaner operator experience. The output should fit the way technicians already work. Nobody needs another dashboard that becomes its own chore.

For now, Tickety is early. Rough in places. Probably missing things that will be obvious after a few real tickets. That is fine. The live demo is there so people can poke at the idea while it is still small enough to change, and the GitHub repo is open for anyone who wants to inspect, fork, or improve it.

The core idea feels right: AI in ITSM should be a sidekick, not a supervisor. It should reduce friction, improve clarity, and leave judgment where it belongs.